Capstone 5. nedēļa: zinātība ir bezjēdzīga bez “zināt, kāpēc” un kā mācīties ietvarus kā inženierim

Iemācīšanās izmantot ietvaru pati par sevi nav programmatūras inženierija. Apgūstot problēmas, kuras ietvarstruktūra atrisina tās problēmu jomā (s), ir tuvāk programmatūras inženierijai. Ja projekts, kurā strādājat, rada izaicinājumus, kas ir daudz tālāk par to, ko var izlabot vienkāršs ietvars, tā ir programmatūras inženierija. Facebook izmanto React, tāpat kā prakses iepirkumu groza lietotne, kuru izveidoju dienu vai divas. Facebook ir neticami inženierijas varoņdarbs; mana iepirkumu groza lietotne nav.

Ir daži aspekti, kas iemācās jaunu instrumentu vai ietvaru, un kas man nepatīk. Man patīk uzzināt par problēmu risināšanas sistēmām vai kompromisiem, ko rada dažādas koda strukturēšanas metodes. Piemēram, es uzskatu, ka Flux dizaina modelis ir vienkārši ģeniāls. Lietotnes izveidošana bez Flux kļūst neticami netīka, jo jums ir jāpāriet lietojumprogrammas stāvoklim cauri daudziem komponentiem, tikai tiem bērnu komponentiem, lai izsauktu garu senču funkciju ķēdi, līdz komponents, kuram pieder valsts, tiek informēts par notikumu vienā. no tā bērniem, mazbērniem, mazbērnu bērniem utt. Flux astronomiski atvieglo domāšanu par to, ko lieto lietotne, kā tiek pārvaldīts tās stāvoklis un par kādiem komponentiem ir atbildīgi pat tad, ja pieaug bāzes bāze.

Tam jāpievērš uzmanība, apgūstot jaunu sistēmu: kādas problēmas tā risina un kā? Kāda ir filozofija, no kuras radās risinājums? Kāda ir vispārējā arhitektūra un kādus sāpju punktus šī arhitektūra ievieš? Kādi preskriptīvi uzskati par to, kā problēma būtu jāatrisina, ir pamatā šī konkrētā risinājuma izveidošanai, un vai jūs piekrītat šiem uzskatiem? Ja jums tie nav kopīgoti, vai ne? Ietvarstruktūra ir daudz vairāk nekā līdzeklis: tā ir deklarācija par to, kā jāatrisina kāda pamatproblēma vai daudzas pamatproblēmas. Kad man ir uzdots iemācīties jaunu rīku vai sistēmu, šos es uzdodu. Man nerūp precīzi atcerēties tīmekļa maisiņa konfigurēšanas nianses: tas nāks ar laiku, un, ja tā neder, tas ir kaut kas, ko es dažu minūšu laikā varu viegli izpētīt. Es varu jautāt google, ko nozīmē kļūdas ziņojums. Es nevaru pajautāt google, vai es piekrītu ietvara dizaina lēmumiem un to ieviestajiem kompromisiem.

Labi apgūstot pamatnoteikumus un ātri apgūstot tos, tie nav savstarpēji izslēdzoši, ja esat apbruņots ar zināšanām par tās jomas pamatiem, kurā strādājat. Jums arī jāpiešķir prioritāte zināšanām saskaņā ar iepriekš izstrādātu darba kārtību. Mana darba kārtība gandrīz vienmēr ir šāda: “Izprotiet“ kāpēc ”tikpat daudz kā“ kā ”. Iemesls ir šāds: Jūs vienmēr lietpratīgāk izmantosit kādu rīku, ja zināt tā esamības iemeslu un tā izstrādes pamatā esošos lēmumus. “Kā?” Un “Kāpēc?” Nav savstarpēji nesaistīti jautājumi, un patiesībā spēcīga izpratne par “Kāpēc” stiprinās jūsu spēju lietot “Kā”. Tas ir tāpēc, ka, ja jūs saprotat, kāpēc rīkam ir specifiskas funkcijas, kas tam piemīt, jums nav vienkārši jāapzinās pats rīks: jums ir izpratne par spriešanas procesiem, kuru izpausme ir rīks. Tas nozīmē, ka tad, kad neizbēgami sastopaties ar tehnisku izaicinājumu, kas nav piemērojams iegaumētajam komandu komplektam un kā rīkoties, varat izmantot paša rīka argumentāciju un virzīties uz risinājumu. Tā ir atšķirība starp ietvara lietotāju un inženieri.

Tātad šonedēļ mēs uzzinājām reactJS kā komandu. Dodiet mums vēl vienu nedēļu, un mēs, iespējams, varētu nosūtīt produkcijas kvalitātes kodu (un faktiski mums tiks dota vēl viena nedēļa). Tas ir tāpēc, ka mēs pietiekami labi saprotam problēmas jomu, lai zinātu, kādām kļūdām vajadzētu pievērst uzmanību (un mēs zinām, kā pārbaudīt, lai novērstu šīs kļūdas). Citiem vārdiem sakot, mēs nedarīsim kaut ko līdzīgu tam, lai izveidotu šifrēšanas apmaiņu, kas pilnībā balstās uz klienta puses apstiprināšanu.