Capstoneov peti tjedan: know-how je beskoristan bez „know-why“ i kako naučiti okvire poput inženjera

Učenje korištenja okvira samo po sebi nije softverski inženjering. Učenje problema koje okvir rješava u svojoj domeni problema bliže je inženjeringu softvera. Ako projekt na kojem radite postavlja izazove koji su daleko izvan onoga što može popraviti puki okvir, to je softverski inženjering. Facebook koristi React, a isto vrijedi i aplikacija za praksu u košarici koju sam izgradio za dan ili dva. Facebook je nevjerojatan podvig inženjerstva; moja aplikacija za košaricu nije.

Postoje neki aspekti učenja novog alata ili okvira u kojima uživam, a neki koji ne. Uživam u učenju o problemima koji rješavaju okviri ili o kompromisima koji su postavljeni različitim metodama strukturiranja koda. Primjerice, uzorak dizajna Flux smatram jednostavno genijalnim. Izgradnja aplikacije bez protoka postaje nevjerojatno neuredna jer morate proći stanje aplikacije kroz mnoštvo komponenti, samo da one podređene komponente nazovu dugi lanac funkcija predaka dok komponenta koja je vlasnik država ne bude obaviještena o događaju u jednom njegove djece, unučadi, prabake i sl. Flux astronomski olakšava razmišljanje o tome što aplikacija radi, kako se upravlja državom i koje su komponente odgovorne čak i za rast kodne baze.

To je ono na što se treba usredotočiti prilikom učenja novog okvira: koje probleme rješava i kako? Koja je filozofija iz koje je nastalo rješenje? Što je opća arhitektura i koje točke boli ta arhitektura uvodi? Koja su propisivanja uvjerenja o tome kako problem treba riješiti informirana o stvaranju ovog određenog rješenja i dijelite li ta uvjerenja? Ako ih ne podijelite, zar ne? Okvir je puno više od alata: to je deklaracija o načinu na koji treba temeljni problem ili mnoge temeljne probleme riješiti. Kad sam zadužen za učenje novog alata ili okvira, to su pitanja koja postavljam. Ne zanima me napamet točne nijanse konfiguriranja webpack-a: to će doći s vremenom, a ako to ne bude, to je nešto što lako mogu istražiti za nekoliko minuta. Mogu pitati google što znači poruka o pogrešci. Ne mogu tražiti google da li su idejne odluke okvira i kompromisi koje uvode one s kojima se slažem.

Dobro učenje i brzo učenje brzo se ne isključuju međusobno ako ste naoružani znanjem osnova domene u kojoj radite. Morate također prioritet dati svoje znanje prema unaprijed zamišljenom programu. Moj dnevni red je gotovo uvijek: „Shvatite„ zašto “jednako koliko i„ kako “. Razlog je sljedeći: Uvijek ćete se više upoznati s alatom ako znate njegov postojeći razlog i razlog (e) za njegove izazove. "Kako?" I "Zašto?" Nisu međusobno nepovezana pitanja, a zapravo, snažno shvaćanje "Zašto" pojačaće vašu sposobnost korištenja "Kako". To je zato što ako razumijete zašto alat ima specifične karakteristike koje posjeduje, tada ne morate samo shvatiti sam alat: morate shvatiti procese rezultiranja, od kojih je alat manifestacija. To znači da kad neminovno naiđete na tehnički izazov koji nije podređen memoriranom skupu naredbi i uputa, možete primijeniti zaključak iza samog alata i usmjeriti svoj put do rješenja. To je razlika između korisnika okvira i inženjera.

Tako smo ovaj tjedan naučili reagirati kao tim. Dajte nam još tjedan dana i vjerojatno bismo mogli isporučiti šifru kvalitete proizvodnje (a u stvari će nam biti dat još tjedan dana). To je zato što dovoljno razumijemo problematičnu domenu da bismo znali na koje greške moramo biti pozorni (i znamo kako testirati kako bismo spriječili ove pogreške). Drugim riječima, nećemo raditi nešto poput izgradnje kripto razmjene koja se u potpunosti oslanja na provjeru na strani klijenta.