Nurgakivinädal 5: oskusteave on mõttetu ilma teadmisteta ja kuidas õppida raamistikke nagu insener

Raamistiku kasutamise õppimine ei ole ise tarkvaratehnika. Raamide oma probleemivaldkonnas lahendatavate probleemide õppimine on lähedasem tarkvaratehnikale. Kui teie töötav projekt kujutab endast väljakutseid, mis ületavad kaugelt selle, mida pelk raamistik suudab lahendada, on see tarkvaratehnika. Facebook kasutab Reaktorit ja samamoodi harjutuskorvirakendus, mille ehitasin päev-paar pärast. Facebook on inseneritöö uskumatu feat; minu ostukorvirakendus pole.

Uue tööriista või raamistiku õppimisel on mõned aspektid, mis mulle meeldivad, ja mõned, mis mulle mitte. Mulle meeldib õppida tundma lahendatavate probleemide raamistikke või kompromisse, mida pakuvad erinevad koodi struktureerimise meetodid. Näiteks leian, et Fluxi disainimuster on lihtsalt geenius. Rakenduse loomine ilma voogudeta on uskumatult segane, kuna peate rakenduse oleku paljude komponentide kaudu läbi laskma, ainult siis, kui lastekomponendid kutsuvad pika esivanemate funktsioonide ahela, kuni riiki omavale komponendile teatatakse sündmusest ühes lastest, vanavanematest, vanaisadest jne. Flux muudab astronoomiliselt lihtsamaks mõtlemise rakenduse toimimisele, selle oleku haldamisele ja sellele, millised komponendid vastutavad isegi siis, kui koodipõhi kasvab.

Sellele tuleb uue raamistiku õppimisel tähelepanu pöörata: milliseid probleeme see lahendab ja kuidas? Milline on filosoofia, millest lahendus sündis? Milline on üldine arhitektuur ja milliseid valupunkte see arhitektuur tutvustab? Millised ettekirjutavad uskumused selle kohta, kuidas probleemi tuleks lahendada, andsid teada selle konkreetse lahenduse loomisest ja kas jagate neid veendumusi? Kui te ei jaga neid, kas peaksite? Raamistik on palju enamat kui tööriist: see on deklaratsioon selle kohta, kuidas tuleks lahendada mõni põhiprobleem või paljud põhiprobleemid. Kui mulle on pandud ülesandeks õppida uut tööriista või raamistikku, siis küsin neid. Mind ei huvita Webpaketi seadistamise täpsete nüansside meeldejätmine: see tuleb ajaga kaasas ja kui seda pole, on see asi, mida saan mõne minutiga hõlpsalt uurida. Ma võin Google'ilt küsida, mida tõrketeade tähendab. Ma ei saa google'ilt küsida, kas raamistiku kujundusotsused ja nendega tutvustatud kompromissid on sellised, millega olen nõus.

Raamistiku hea õppimine ja selle kiire õppimine ei välista üksteist, kui olete relvastatud teadmistega selle valdkonna põhialustest, kus töötate. Samuti peate oma teadmised tähtsustama vastavalt eelnevalt kavandatud päevakavale. Minu päevakava on peaaegu alati: “Mõistage“ miks ”täpselt samamoodi kui“ kuidas ”. Põhjus on järgmine: Teil on tööriista valdamine alati suurem, kui teate selle olemasolu põhjust ja selle väljatöötamise aluseks olevate otsuste põhjust. “Kuidas?” Ja “Miks?” Ei ole omavahel seotud küsimused ja tegelikult tugev “Miks” mõistmine tugevdab teie võimet kasutada “Kuidas”. Selle põhjuseks on asjaolu, et kui mõistate, miks tööriistal on spetsiifilisi funktsioone, siis ei saa te lihtsalt tööriista enda käest aru saada: teil on mõistmisprotsesside mõistmine, millest tööriist on manifestatsioon. See tähendab, et kui puutute paratamatult kokku tehnilise väljakutsega, mida ei saa meelde jätta käskude ja juhiste jaoks, saate rakendada tööriista enda mõttekäiku ja liikuda lahenduseni. See on erinevus raamistiku kasutaja ja inseneri vahel.

Nii õppisime sel nädalal meeskonnana reageerima. Andke meile veel üks nädal ja me võiksime tõenäoliselt saata toodangu kvaliteedikoodi (ja tegelikult antakse meile veel üks nädal). Selle põhjuseks on see, et mõistame probleemivaldkonda piisavalt, et teada, milliseid vigu tuleb otsida (ja me teame, kuidas testida nende vigade ärahoidmiseks). Teisisõnu ei tee me midagi sellist nagu krüptovahetuse ehitamine, mis tugineb täielikult kliendipoolsel valideerimisel.