Capstone 5. hét: A know-how haszontalan a „know-why” és a „Hogyan kell megtanulni a kereteket”, mint mérnök

A keret használatának megtanulása önmagában nem szoftverfejlesztés. A keretek által a problémakörében megoldott problémák megismerése közelebb áll a szoftverfejlesztéshez. Ha a dolgozó projekt olyan kihívásokat vet fel, amelyek messze túlmutatnak azon, amit egy egyszerű keret képes megjavítani, az a szoftverfejlesztés. A Facebook a Reakciót használja, és ugyanaz a gyakorlati bevásárlókosár-alkalmazás, amelyet egy-két nap alatt beépítettem. A Facebook hihetetlen mérnöki teljesítmény; a bevásárlókosárom alkalmazása nem.

Van néhány szempont az új eszköz vagy keret megtanulása szempontjából, amely élvezem, és vannak, amelyek nem. Nagyon örülök annak, hogy megismerjem a problémakeretek megoldását, vagy a kód strukturálásának különböző módszerei által okozott kompromisszumokat. Például úgy találom, hogy a Flux tervezési mintája egyszerűen zseniális. Egy alkalmazás Flux nélkül történő elkészítése hihetetlenül rendetlenné válik, mivel az alkalmazás állapotát sok komponensen keresztül kell átadnia, csak azoknak a gyermekkomponenseknek, amelyek hosszú ősi funkciók láncát hívják fel mindaddig, amíg az állam tulajdonában lévő elem nem értesül az eseményről egyben. gyermekei, unokája, unokája stb. A Flux csillagászati ​​szempontból megkönnyíti a gondolkodást arról, hogy egy alkalmazás mit csinál, hogyan működik az állapota, és milyen összetevők felelősek még akkor is, ha a kódbázis növekszik.

Erre kell összpontosítani egy új keret elsajátításakor: milyen problémákat old meg és hogyan? Mi a filozófia, amelyből a megoldás született? Mi az általános építészet és milyen fájdalompontot vezet be ez az építészet? Milyen előíró vélemények arról, hogy a problémát hogyan kell megoldani, befolyásolták ennek a megoldásnak a megalkotását, és megosztja ezeket a hiedelmeket? Ha nem osztja meg őket, ugye? A keret sokkal több, mint eszköz: ez egy nyilatkozat arról, hogy miként kell megoldani egy alapvető problémát, vagy sok alapvető problémát. Amikor feladatom egy új eszköz vagy keret megtanulása, ezeket kérdezem. Nem érdekel, hogy megjegyezem-e a webpack konfigurálásának pontos árnyalatait: ez az idő múlásával megtörténik, és ha nem, akkor valami olyat, amit perc alatt könnyen megkutathatok. Megkérdezhetem a Google-tól, hogy mit jelent egy hibaüzenet. Nem tudom megkérdezni a Google-tól, hogy egy keretrendszer tervezési döntéseivel és az általuk bevezetett kompromisszumokkal egyetértek-e.

A keretrendszer megfelelő megtanulása és gyors megtanulása nem zárják ki egymást, ha felfegyverkeznek a dolgozó terület alapjainak ismeretében. Tudását is egy előre megtervezett napirend szerint kell rangsorolnia. A napirendem szinte mindig: „értsd meg a„ miért ”ugyanúgy, mint a„ hogyan ”. Ennek oka a következő: Mindig jobban ismeri az eszközt, ha ismeri annak létezésének okát és a kialakítás mögött meghúzódó döntések okát. A „Hogyan?” És a „Miért?” Nem független kérdések, és valójában a „Miért” erőteljes megértése megerősíti a „Hogyan” használatának képességét. Ennek oka az, hogy ha megérti, hogy az eszköz miért rendelkezik a sajátosságaival, akkor nem csak megérti magát az eszközt: megérti az érvelési folyamatokat, amelyeknek az eszköz egy megnyilvánulása. Ez azt jelenti, hogy ha elkerülhetetlenül olyan technikai kihívással szembesül, amely nem felel meg a memorizált parancsoknak és a használati utasításoknak, akkor alkalmazhatja az eszköz mögött található érvelést, és navigálhat a megoldás felé. Ez a különbség a keretfelhasználó és a mérnök között.

Tehát megtanultuk a reactJS-t mint egy csapatot ezen a héten. Adj nekünk még egy hetet, és valószínűleg megküldhetjük a gyártás minőségi kódját (és valójában újabb hetet kapunk). Ennek oka az, hogy annyira megértjük a problémát, hogy tudjuk, mely hibákat kell figyelnünk (és tudjuk, hogyan kell tesztelni ezeket a hibákat.) Más szóval, nem fogunk csinálni valamit, mint például egy kriptográfia cseréjét, amely teljes mértékben az ügyféloldali érvényesítésen alapul.