Capstone Week 5: Know-how jest bezużyteczne bez „know-how” i jak nauczyć się frameworków jak inżynier

Nauka korzystania z frameworka sama w sobie nie jest inżynierią oprogramowania. Poznanie problemów, które platforma rozwiązuje w swoich domenach problemowych, jest bliższe inżynierii oprogramowania. Jeśli projekt, nad którym pracujesz, wiąże się z wyzwaniami wykraczającymi daleko poza to, co zwykły szkielet może naprawić, to inżynieria oprogramowania. Facebook używa React, podobnie jak aplikacja koszyka na zakupy, którą zbudowałem w dzień lub dwa. Facebook to niesamowite osiągnięcie inżynieryjne; moja aplikacja koszyka nie jest.

Są pewne aspekty uczenia się nowego narzędzia lub struktury, które lubię, a niektóre nie. Lubię się uczyć o problemach rozwiązywanych przez frameworki lub kompromisach związanych z różnymi metodami strukturyzacji kodu. Na przykład uważam, że wzór Flux jest po prostu genialny. Budowanie aplikacji bez Fluxa staje się niezwykle nieuporządkowane, ponieważ musisz przekazać stan aplikacji przez wiele komponentów, tylko w przypadku tych komponentów potomnych, które wywołują długi łańcuch funkcji nadrzędnych, dopóki komponent będący właścicielem stanu nie zostanie powiadomiony o zdarzeniu w jednym swoich dzieci, wnuków, prawnuków itp. Flux sprawia, że ​​astronomicznie łatwiej jest myśleć o tym, co robi aplikacja, jak zarządza jej stanem i za jakie elementy są odpowiedzialne, nawet gdy baza kodów rośnie.

Na tym należy się skupić, ucząc się nowych ram: jakie problemy rozwiązuje i jak? Z jakiej filozofii powstało rozwiązanie? Jaka jest ogólna architektura i jakie bolączki wprowadza ta architektura? Jakie przekonania dotyczące tego, jak należy rozwiązać problem, przyczyniły się do stworzenia tego konkretnego rozwiązania i czy podzielasz te przekonania? Jeśli nie udostępniasz ich, powinieneś? Ramy to coś więcej niż narzędzie: to deklaracja o sposobie rozwiązania podstawowego problemu lub wielu podstawowych problemów. Kiedy mam za zadanie nauczyć się nowego narzędzia lub struktury, oto pytania, które zadaję. Nie dbam o zapamiętywanie dokładnych niuansów konfiguracji webpacka: przyjdzie to z czasem, a jeśli nie, jest to coś, co mogę łatwo zbadać w kilka minut. Mogę zapytać google, co oznacza komunikat o błędzie. Nie mogę zapytać google, czy decyzje projektowe ram i kompromisy, które wprowadzają, są tymi, z którymi się zgadzam.

Uczenie się dobrze frameworka i szybkie uczenie się go nie wykluczają się nawzajem, jeśli jesteś uzbrojony w wiedzę o podstawach dziedziny, w której pracujesz. Musisz także uszeregować swoją wiedzę według priorytetów zgodnie z wcześniej ustalonym programem. Moim celem jest prawie zawsze: „Zrozumieć„ dlaczego ”tak samo jak„ jak ”. Powód jest następujący: zawsze będziesz bardziej biegły w posługiwaniu się narzędziem, jeśli znasz jego powód istnienia i powód (decyzje) leżące u podstaw jego projektu. „Jak?” I „Dlaczego?” Nie są pytaniami niezwiązanymi ze sobą, a tak naprawdę posiadanie silnego zrozumienia „Dlaczego” wzmocni Twoją umiejętność posługiwania się „Jak”. Dzieje się tak dlatego, że jeśli rozumiesz, dlaczego narzędzie ma określone funkcje, które posiada, to nie masz pojęcia o samym narzędziu: masz wiedzę na temat procesów wnioskowania, których narzędzie jest manifestacją. Oznacza to, że gdy nieuchronnie napotkasz wyzwanie techniczne, które nie jest możliwe do zapamiętania w zestawie poleceń i poradników, możesz zastosować uzasadnienie samego narzędzia i przejść do rozwiązania. Taka jest różnica między użytkownikiem frameworka a inżynierem.

W tym tygodniu nauczyliśmy się reagować jako zespół. Daj nam kolejny tydzień, a prawdopodobnie moglibyśmy wysłać kod jakości produkcji (i faktycznie dostaniemy kolejny tydzień). Wynika to z tego, że rozumiemy domenę problemów wystarczająco dobrze, aby wiedzieć, na jakie błędy należy uważać (i wiemy, jak testować, aby zapobiec tym błędom). Innymi słowy, nie zrobimy czegoś takiego jak zbudowanie giełdy kryptograficznej, która całkowicie opiera się na weryfikacji po stronie klienta.