Teden Capstone 5: Know-how je nekoristno brez "know-how" in Kako se učiti okvirov kot inženir

Učenje uporabe ogrodja samo po sebi ni inženiring programske opreme. Učenje problemov, ki jih okvir rešuje v svojih (-ih) področjih (problematika), je bližje programskemu inženiringu. Če projekt, na katerem delate, predstavlja izzive, ki so daleč zunaj tega, kar lahko določi zgolj okvir, to je programska oprema. Facebook uporablja React in tako tudi aplikacijo za nakupovalne vozičke, ki sem jo zgradil v dnevu ali dveh. Facebook je neverjeten podvig inženiringa; moja aplikacija za nakupovalno košarico ni.

Obstaja nekaj vidikov učenja novega orodja ali okvira, v katerem uživam, in nekaterih, ki jih ne. Uživam v spoznavanju težav, ki jih rešujejo okviri, ali kompromisov, ki jih predstavljajo različne metode strukturiranja kode. Na primer, vzorec oblikovanja Flux se mi zdi preprosto genij. Izdelava aplikacije brez Fluxa postane neverjetno zmedena, saj morate stanje aplikacije prenesti skozi množico komponent, samo da tisti nadrejeni sestavni deli pokličejo dolgo verigo funkcij prednikov, dokler komponenta, ki je lastnica države, ne obvesti o dogodku v enem njegovih otrok, prababcev, pradedov itd. Flux astronomsko olajša razmišljanje o tem, kaj počne aplikacija, kako se upravlja z njenimi državami in katere komponente so odgovorne tudi, ko širi baza podatkov.

Na to se moramo osredotočiti pri učenju novega okvira: katere težave rešuje in kako? Kakšna je filozofija, iz katere se je rodila rešitev? Kaj je splošna arhitektura in kakšne bolečine kaže ta arhitektura? Katera predpisana prepričanja o tem, kako je treba rešiti težavo, so bila obveščena o oblikovanju te posebne rešitve in ali ta prepričanja delite? Če jih ne delite, ali ne? Okvir je veliko več kot orodje: je izjava o načinu reševanja temeljnega problema ali številnih temeljnih težav. Ko sem zadolžen za učenje novega orodja ali okvira, so to vprašanja. Ne zanima me, kako si zapomnim natančne odtenke konfiguriranja spletnega paketa: to bo prišlo s časom, in če ne gre, lahko v nekaj minutah enostavno raziskujem. Lahko vprašam google, kaj pomeni sporočilo o napaki. Ne morem vprašati google, če so oblikovalske odločitve okvira in kompromisi, ki jih uvajajo, tisti, s katerimi se strinjam.

Če se dobro učite okvirja in se ga hitro naučite, se medsebojno ne izključujeta, če ste oboroženi s poznavanjem osnov področja, na katerem delate. Prav tako morate svoje znanje prednostno določiti v skladu s predhodno zasnovano agendo. Moj dnevni red je skoraj vedno: "Razumevanje" zakaj "ravno toliko kot" kako ". Razlog je ta: Z orodjem boste vedno bolj izkušeni, če poznate njegov vzrok za obstoječe in razlog za odločitve, ki stojijo za njegovo zasnovo. »Kako?« In »Zakaj?« Nista povezana vprašanja in dejansko, če se boste močno razumeli z »Zakaj«, boste okrepili vašo sposobnost uporabe »Kako«. To je zato, ker če razumete, zakaj ima orodje posebne lastnosti, ki jih ima, potem ne razumete samo orodja: razumete procese sklepanja, katerih orodje je manifestacija. To pomeni, da kadar neizogibno naletite na tehnični izziv, ki ga ni mogoče zabeležiti v zapomnjenem nizu ukazov in navodil, lahko uporabite orodje za samo orodje in se usmerite na rešitev. To je razlika med uporabnikom okvirja in inženirjem.

Tako smo se ta teden naučili reagirati kot ekipa. Dajte nam še en teden in verjetno bomo lahko poslali kodo kakovosti proizvodnje (in v resnici nam bodo dodelili še en teden). To je zato, ker problematično domeno razumemo dovolj, da vemo, na katere napake moramo biti pozorni (in vemo, kako testirati, da te napake preprečimo). Z drugimi besedami, ne bomo storili kaj takega, kot bi zgradili kripto izmenjavo, ki se v celoti zanaša na preverjanje na strani odjemalca.