oglądałem / słuchałem tego wspaniałego wykładu Simona Browna na temat modularnych monolitów z GOTO 2018.
w tym wspomina termin zwany Cargo Cult Programming i to naprawdę uderzyło we mnie akord.
niedawno dołączyłem do nowej firmy z nowym językiem programowania, nowymi narzędziami, nowymi procesami i nowym zespołem. Właściwie to wszystko jest „nowe”.
to spowodowało, że w ostatnich miesiącach wiele się nauczyłem. Będąc stosunkowo doświadczonym, lubię patrzeć na „Dlaczego”, a nie na ” jak ” podczas uczenia się nowych rzeczy. Zdałem sobie sprawę, że nie jest to najczęstsze podejście.
gdy użytkownik ma za zadanie dodanie do istniejącej bazy kodu, rozszerzenie obecnego rozwiązania, najprawdopodobniej sprawdzi, jak zostało to zrobione wcześniej, kopiując podejście do swojego rozwiązania. Mogą / będą ślepo podążać za tym wzorcem, tak jak to było zrobione wcześniej. Dodatkowe bloki są dodawane na szczycie wieży, nie zastanawiając się, czy jest to słuszne. Jeśli wszyscy to zrobią, to w końcu się stanie.
stąd pochodzi termin „Cargo Cult Programming”.
Wikipedia wyjaśnia to tak:
Cargo cult programming to styl programowania komputerowego charakteryzujący się rytualnym włączaniem kodu lub struktur programowych, które nie służą żadnemu rzeczywistemu celowi. Programowanie Cargo cult jest typowo symptomatyczne dla programisty, który nie rozumie ani błędu, który próbował rozwiązać, ani pozornego rozwiązania (porównaj debugowanie shotgun, deep magic). Termin Cargo Cult programmer może mieć zastosowanie, gdy niewykwalifikowany lub początkujący programista komputerowy (lub niedoświadczony w danym problemie) kopiuje jakiś kod programu z jednego miejsca do drugiego, nie rozumiejąc w niewielkim stopniu, jak to działa, lub czy jest to wymagane w nowej pozycji.
Programowanie Cargo cult może również odnosić się do praktyki stosowania wzorca projektowego lub stylu kodowania ślepo, nie rozumiejąc przyczyn leżących u podstaw tej zasady projektowania. Przykładami są dodawanie niepotrzebnych komentarzy do samodzielnego kodu, nadgorliwe przestrzeganie konwencji określonego paradygmatu programowania lub dodawanie kodu usuwania obiektów, które automatycznie pobrałyby garbage collection.
wyobraź sobie scenariusz, w którym pracujesz nad błędem, znajdując kod powodujący błąd. Nie jesteś pewien, co się dzieje, więc;
- Google Błąd.
- znajdujesz pytanie StackOverflow.
- wyszukaj najbardziej wyszukaną odpowiedź.
- skopiuj i wklej rozwiązanie do kodu.
- spróbuj debugować, aby zobaczyć, czy to naprawiło twój problem.
ma, więc sprawdź to i ruszaj dalej.
brzmi znajomo?
dlaczego to robimy? Dlaczego ślepo bierzemy ten fragment i używamy go tak, jak jest, w naszej implementacji?
przypadek użycia prawdopodobnie nie jest taki sam, więc byłbym zaskoczony, gdyby rozwiązania były. Pomijając proste przykłady, zrozumienie rozumowania stojącego za rozwiązaniem jest ważniejsze niż samo rozwiązanie. Jest wiele rzeczy, których nie możesz zrobić z czymś, czego nie rozumiesz. Nie można go modyfikować, ulepszać ani testować. Nie możesz tego udokumentować i nie możesz być właścicielem.
wszyscy kochamy to, co nowe, a kierownictwo szczególnie lubi podążać za popularnymi trendami, nadążając za postępem technologicznym.
większość zespołów będzie teraz stosować zwinne podejście. TDD i testy automatyczne mogą być bardzo przydatne w niektórych scenariuszach, ciągła Integracja usuwa znaczną część kosztów z zespołu ds. infrastruktury, Big Data i AI mogą znacznie poprawić zadowolenie użytkowników i Konteneryzację, a ostatnio mikroserwisy zmieniają naszą starą architekturę monolitu w mniejsze samodzielne usługi.
każdy z tych osiągnięć jest genialny sam w sobie i nie pochwalam żadnego z nich. Moim problemem jest to, czy musimy je wszystkie zaadoptować do wszystkich naszych procesów i kodu? Widzimy posty na blogach z Netflix, Facebook, Twitter pokazujące, jak ich użycie zmieniło sposób ich pracy. Jeśli duże firmy uznają je za konieczne, czy my też nie? To tutaj program Cargo cult ponownie podnosi swoją brzydką głowę.
musimy zrozumieć problemy z naszymi obecnymi projektami, dlaczego tak się stało i jak można je wyrzucić w przyszłości. Tak, te nowe procesy mogą nam pomóc w rozwiązywaniu naszych problemów, ale ślepe podążanie za nimi w słabej nadziei, że to zrobią, nie jest drogą naprzód, ani nie ma żadnego logicznego sensu.
wspominam konkretnie o Mikroserwisach, ponieważ wiele firm zdaje się dokonywać transformacji, powołując się na takie korzyści jak:
- szybszy czas rozwoju
- wysoka skalowalność
- łatwe Ulepszanie
- łatwość wdrażania
- autonomiczne zespoły ze swobodą wyboru technologii
przy takiej liście, o czym tu myśleć? Niech wszyscy wskoczą na modę!
poczekaj chwilę… czy są jakieś wady tego podejścia?
- złożoność architektury
w architekturach monolitycznych złożoność i liczba zależności znajdują się wewnątrz bazy kodu, podczas gdy w architekturach mikroserwisów złożoność przenosi się do interakcji poszczególnych usług, które implementują określoną domenę
- złożoność operacyjna
- jak zapewnić zasoby w skalowalny i opłacalny sposób
- jak skutecznie obsługiwać dziesiątki lub setki komponentów Mikroserwisowych bez zwielokrotniania wysiłków
- jak radzić sobie z brakiem standardów i heterogenicznością środowiska, które zawierają różne technologie i osoby o różnych umiejętnościach
- jak radzić sobie z wersjonowaniem
- jak śledzić i debugować interakcje w całym systemie
- jak śledzić setki potoków wdrożeń kodu i ich współzależności
zostały one zaczerpnięte z własnego dokumentu firmy Amazon „Challenge of Microservices”. Nie wiem jak wy, ale wady wyglądają dla mnie bardziej przerażająco niż korzyści. Po raz kolejny, nie mówię, że nie jest to właściwe podejście, aby zejść w dół, ale jeśli te korzyści przeważają nad wadami, co zyskujesz stosując to podejście?
problem „publiczny”.
to naprawdę proste, przestań używać słowa kluczowego Public, przestań automatycznie tworzyć klasy publiczne. Dlaczego to robimy?
problem z użyciem publicznego słowa kluczowego polega na tym, że tracisz korzyści związane z enkapsulacją. Dlaczego używamy go tak często? Jest to prawie domyślne słowo, którego używamy podczas tworzenia klas, wszystkie przykłady będą używać klas publicznych, kreatory i urywki będą implementować klasy publiczne. Czas przestać. Ile osób ma publiczne konto na Facebooku? Większość rzeczy na tym świecie jest prywatna, podobnie jak nasze klasy. Ustaw je domyślnie jako prywatne, a następnie, jeśli chcesz, aby były publiczne, zmień je wtedy.
z wielkim doświadczeniem przychodzi wielka obawa.
im dłużej jesteś w polu, tym mniej naiwny jesteś w postrzeganiu ulepszeń, które przyniesie nowe narzędzie lub proces. Większość dzisiejszych pomysłów pochodzi z wieloletnich badań w tej dziedzinie, które w końcu zostały przyjęte. Gdy coś zyskało masową adopcję, łatwiej jest czuć się komfortowo z obejmowaniem go w pełni. Jeśli tak trzeba.
„dobry osąd pochodzi z doświadczenia, a doświadczenie pochodzi z złego osądu”
– Rita Mae Brown
więc nie krępuj się przeszukiwać interwebów w poszukiwaniu rozwiązań i samouczków do swoich problemów; odkrywaj nowe języki, frameworki i implementacje. Po prostu bądź świadomy, dlaczego działają, a nie po prostu jak. Wszyscy uczymy się na własnych doświadczeniach i błędach, więc zrozumienie podstaw powstrzyma was od podążania tą samą ścieżką w przyszłości.