culting Cargo jest nieunikniony

to niekontrowersyjne, że nowi programiści nie mogą pomóc, ale cult cargo.Po prostu nie nauczyli się wystarczająco dużo stosu, aby naprawdę zrozumieć, co dzieje się pod maską i dlaczego rzeczy muszą być zrobione w określony sposób.

na jednym z moich pierwszych kursów programowania dowiedzieliśmy się, że w Javie punktem wejścia do programu jest:

public static void main(String args)  

dojście do punktu, w którym Rozumiem każdą część podpisu tej metody Zajęło mi lata.Nawet gdyby mi to wtedy wyjaśniono, nie zrozumiałbym tego.Musiałbym zrozumieć widoczność metod, metody klasy kontra instancji, typy zwracania, typy parametrów, tablice (w przeciwieństwie do list/wektorów), argumenty wiersza poleceń (i sposób ich parsowania przez powłokę) i różne szczegóły dotyczące implementacji Javy.

i to jest OK.Okazuje się, że nie trzeba rozumieć żadnej z tych rzeczy, aby napisać wiersz poleceń, a nawet programy GUI w Javie.

nie oczekujemy, że nowi Programiści poznają tajniki każdej podejmowanej decyzji.Po prostu nie programowali wystarczająco długo, aby zrozumieć każdy szczegół każdej części stosu.

nie oczekujemy, że będą wiedzieć, że Git przechowuje commity w ukierunkowanym grafie acyklicznym, a każda gałąź jest wskaźnikiem do jednego węzła w graph.It jest na tyle dobry, że mogą robić git checkout I git commit I kontynuować swoją pracę.I jest to wystarczająco dobre, jeśli postępują zgodnie z zasadą „nigdy fast-forward merge” (lub „always fast-forward merge”).

ale nawet dla starszych programistów jest to nieuniknione.Co senior dev tak naprawdę rozumie wszystkie polecenia Gita, które muszą sprawdzić na Stack Overflow?Lubawk Ised część one-linera, którą wczoraj sprawdzili na Githubie?Czy każdy nagłówek w odpowiedzi HTTP, z którym odpowiada API aplikacji internetowej?Lub kiedy używać HTTPS vs. URL SSH z repozytorium GitHub?Lub jak najlepiej skonfigurować lokalną instancję PostgreSQL?Czy Twoja instancja Neo4j?Lub jak debugować konfigurację rvm/rbenv / chruby / virtualenv bez wysadzania go i odbudowy od zera?

jedynym sposobem na nie jest wiedza o wszystkim.I nikt nie wie wszystkiego.

kultywacja ładunku jest dobra

kultywacja ładunku jest dobra, gdy jest używana responsibly.It oszczędza nam wiedzy o wszystkim.Gdy jest dobrze używany, jest to akt wykorzystania ciężko zdobytej wiedzy wszystkich innych w tej dziedzinie.Prawdopodobnie, używając jakiejkolwiek abstrakcji w ogóle bez zrozumienia, jak to działa (co jest cały sens abstrakcji!) jest zbiorem ładunków według definicji Lipperta.

ponadto często dobrym wyborem jest culting ładunków.”Ci ludzie zdają się wiedzieć, co robią, więc pójdę za nimi” – to całkowicie racjonalna strategia.

w rzeczywistości społeczność programistyczna aktywnie zachęca do kultywowania ładunków.Kiedy mówimy ludziom: „nie używaj globalnego stanu” lub: „podążaj za PEP8”, to mówimy im, żeby nie używali globalnego stanu.Na przykład, programista idealnie zrozumiałby (czasami nie tak) subtelne sposoby, w jakie stan globalny może cię ugryźć, ale dopóki zrozumienie nie jest dostępne, lepiej po prostu go unikać.

kilka innych świetnych zastosowań cultingu ładunku:

• „Convention over configuration” jak widać w Rails (i jego niezliczonych klonach), Django i Ember.js
• Przewodniki stylowe i ich narzędzia, takie jak Rubocop, JSLint i Auto PEP8
• wiele narzędzi do analizy statycznej, takich jak CodeClimate, Reek, Flay i Flog
• wytyczne aplikacji 12factor
• code smells

jak odpowiedzialny Kult ładunku

oczywiście Kult ładunku ma kilka poważnych wad, ale teraz widzieliśmy kilka up-sides, też.Chcielibyśmy korzystać z narzędzi i technik, które wykonują zadanie już teraz, bez konieczności pełnego zrozumienia, dlaczego one działają.Zamiast całkowicie unikać kultywacji ładunków, jak możemy skutecznie kultywować ładunki?

jedno wielkie zastrzeżenie: nieodłącznym ryzykiem kultywacji ładunków jest to, że nie będziesz w stanie przewidzieć, co pójdzie nie tak, ani nawet klasy problemów, które możesz napotkać, ponieważ zasadniczo nie rozumiesz podejmowanych decyzji.To powiedziawszy, oto kilka wskazówek.

pisanie testów

możesz pisać testy automatyczne, aby upewnić się, że Twój kod działa zgodnie z oczekiwaniami, nawet jeśli nie rozumiesz, dlaczego kod działa.Prostym przykładem może być skopiowanie i wklejenie algorytmu sortującego z przepełnienia stosu, można napisać dla niego test, aby upewnić się, że działa.

bądź jednak ostrożny, ponieważ testowanie nie jest tak dobre w udowodnieniu, że nie ma nieoczekiwanych skutków ubocznych lub krawędzi cases.In przykład algorytmu sortowania, nie będziesz wiedział, o które przypadki brzegowe musisz się martwić.

Refactor

im czystszy kod zachowasz, tym łatwiej będzie zrozumieć, kiedy należy zmienić decyzję dotyczącą ładunku.I pamiętaj, że nie można skutecznie refaktorować bez testów.

Wyizoluj kod Cargo culted

Jeśli to możliwe, Wyizoluj kod cargo culted na klasę lub moduł.Im bardziej możesz go odizolować, tym bardziej ograniczasz jego potencjalne obrażenia.Ponadto, im jest bardziej izolowany, tym łatwiej będzie go zastąpić lub przepisać, gdy zrozumiesz więcej na ten temat.

nie ładuj cult w krytycznych częściach aplikacji

na przykład, jeśli wysoka współbieżność jest absolutną koniecznością dla Twojej aplikacji, prawdopodobnie nie uda Ci się skopiować jakiegoś kodu wątku z przepełnienia stosu.Nawet wybór języka, który z natury dobrze obsługuje współbieżność (takiego jak Elixir, Go lub Clojure), nie rozwiąże Twojego problemu w magiczny sposób.Niestety (lub na szczęście), naprawdę trzeba będzie kopać i nauczyć się czegoś.

nie ładuj się, jeśli awaria prowadzi do złych rzeczy

Jeśli bezpieczeństwo, prywatność, pieniądze itp. są zagrożone, nie cargo cult.Jako oczywisty przykład, jeśli czyjś pace-maker uruchamia pewien C one-liner skopiowany z Stack Overflow, cholera-lepiej wiedzieć, dlaczego twój mały trick działa i jakie są przypadki awarii i skutki uboczne.

unikaj kultywacji ładunku, gdy masz do czynienia ze zmiennymi wejściami

na przykład, jeśli nie znasz awk super dobrze, a wejście do twojego awk one-liner będzie pochodzić z danych wejściowych użytkownika, prawdopodobnie się zepsuje.Jeśli możesz przewidzieć różne formy danych wejściowych, pomoże to, ale powinieneś pamiętać, że prawdopodobnie złamie się w przypadkach wejściowych, których nie byłeś w stanie przewidzieć.

Monitor w produkcji

tylko dlatego, że działa na Twojej maszynie, nie zakładaj, że będzie działać w produkcji, gdzie środowisko jest inne, a użytkownicy robią rzeczy, których nigdy nie brałeś pod uwagę.Monitorowanie błędów, WYJĄTKÓW, błędów twierdzeń i wydajności może poinformować Cię, czy coś jest nie tak, zanim użytkownicy, klienci lub szef zdadzą sobie z tego sprawę.

przegląd kodu, programowanie par, narzędzia do analizy statycznej itp.

uzyskaj inne oczy, wirtualne lub inne, aby spojrzeć na Twój kod.Programowanie w parach i przegląd kodu są oczywistymi przykładami, ale pomocne mogą być również narzędzia do analizy statycznej (np. CodeClimate).Oprócz wyłapywania oczywistych błędów, są one szczególnie pomocne w wskazywaniu kodu, który może nie zawsze działać zgodnie z oczekiwaniami.

przejdź do głębszego zrozumienia

zaczynając od cultingu ładunków, kiedy zdecydujesz się zagłębić w temat, będziesz mieć już pewien kontekst.Ścieżką do głębszego zrozumienia może być samouczenie się, mentoring, programowanie w parze lub po prostu robienie tego samemu dla dobra nauki.

to stara wiadomość

wymienione powyżej wskazówki są prawdopodobnie wszystkim, co słyszałeś wcześniej.To dlatego, że wszyscy pracujemy z ograniczoną wiedzą.Cały czas rozwijamy intuicję, techniki i wytyczne, dzięki którym możemy posuwać się naprzód z częściową wiedzą i ograniczać szkody, jakie możemy wyrządzić.Zamiast nigdy cargo cult, dobrzy Programiści uczą się skutecznie cargo cult.