Jedno proste pytanie, które uprości twój kod
Długość wpisu: 8 min
Miałem kiedyś kolegę w zespole, który wpadł w bardzo niefajną pułapkę.
Dostaliśmy od klienta wymaganie, które mówiło o tym, że chciałby wysyłać maile z systemu.
No to usiadł, wszedł we flow zone i po około tygodniu wyszedł z gotowym rozwiązaniem. Po kilku dniach pracy zacząłem się zastanawiać, czemu to tak długo trwa. Bo w sumie prosty ficzer.
Kolega był seniorem i naszym tech leadem. Kodzik był wypchany dobrymi praktykami - były wzorce, SOLID, generyczność, clean code, email managery, template providery, mnóstwo mądrych klas, wszystko, co najlepsze.
Było tak czysto, że jedynym problemem bandy juniorów, do której należałem i która miała zrobić code review było to, że nawet wspólnymi siłami nie byliśmy w stanie zrozumieć tego kodu 😂.
W naszych oczach klient potrzebował zaimplementować prosty ficzer do wysyłania maili, żeby wysyłać kilka prostych wiadomości z określonym templejtem.
Na nasze oko, ficzer nie potrzebował 80% napisanego kodu. Dlatego nie potrafiliśmy zrozumieć, dlaczego kod jest tak skomplikowany.
Gdy ktoś w końcu spytał, dlaczego to musi być takie skomplikowane, to dostaliśmy, prostą i krótką odpowiedź:
Bo tak się robi.
“Bo tak się robi” to pułapka, która doprowadziła do kilku rzeczy:
- większość zespołu miała utrudnioną pracę przez wiele tygodni, ciężko się pracuje, gdy kod jest niepotrzebnie pogmatwany (aka “czysty do porzygu”)
- byliśmy mocno wkurzeni, bo jedynym argumentem, jaki otrzymaliśmy jest “bo tak się robi” i wiedzieliśmy, że to gówno prawda
- klient nie potrzebował tak skomplikowanego kodziku, który robił dużo magicznych rzeczy, więc jego pieniądze zostały zmarnowane dwukrotnie - na napisanie kodu i potem na utrzymywanie
Finalnie, po wstępnej fali irytacji, mniej lub bardziej gwałtownych gównoburzach i po tygodniach pracy wyrzuciliśmy, albo przepisaliśmy te 80% niepotrzebnego kodu. Czyli w sumie zmarnowaliśmy kasę klienta trzykrotnie.
Owce są wśród nas
Możliwe, że spotkałeś się z podobnymi przypadkami. Przychodzą pod różną postacią.
Ktoś Ci powiedział, że musisz zastosować Wspaniały Wzorzec Projektowy, Który Rozwiąże Wszystkie Twoje Problemy, bo tak się robi. Bo nie ma czasu, żeby teraz to tłumaczyć.
Że musisz coś zrobić w określony sposób, bo ktoś ma takie, a nie inne preferencje albo wyczytał na grupie na Facebooku, że tak się robi.
Że nie możesz czegoś napisać w taki prosty sposób, jak chciałeś, bo gdy nadejdzie Straszny Przypadek Brzegowy, to przecież cała apka się wysypie.
Może się wysypie.
A może ktoś Ci właśnie wciska powtarzany od dłuższego czasu bullshit, który nie ma żadnego zastosowania w Twojej obecnej sytuacji.
Jakiś czas temu mieliśmy boom na mikroserwisy. Ludzie zaczęli się jarać architekturą Netflixa i ich tysiącem mikroserwisów. Wieść się rozniosła, że to takie fajne i zaczęli szatkować swoje apki na mikroserwisy.
W wielu przypadkach było to uzasadnione.
Jednak bardzo często ludzie zapomnieli o tym, że Netflix, to gigant z bardzo specyficznym zestawem problemów do rozwiązania, które są dalekie od problemów przeciętnych projektów.
Przez to wiele aplikacji, które były z natury monolitami zostało przepisanych na mikroserwisy, bo jacyś inni ludzie w internecie mówili, że teraz tak się robi. Potem te projekty zaczęły upadać i nie dało się ich sensownie utrzymywać. Bo czasem monolit musi zostać monolitem, żeby mógł sensownie działać.
Zamiast zoptymalizować pod zmianę i pod swoje okoliczności, programiści optymalizowali pod trendy. Wpadli w tę samą pułapkę, co mój kolega - “bo tak się teraz robi”.
W głowie wyobrażam to sobie jako osobę, która siedzi na krześle, plącze sznurówki swoich dwóch butów ze sobą, a potem wstaje i od razu wywala się na twarz.
Jedną z najczęściej przekazywanych legend z mojego otoczenia jest to, że Reacta trzeba używać z Reduxem.
Nie trzeba. I zastanawiam się skąd się to wzięło. Podejrzenie jest takie, że jak owieczki czytamy tutoriale, gdzie do Reacta ktoś zawsze dokleja Reduxa i potem robimy to samo, komplikując sobie życie.
W dokumentacji Reacta nie jest napisane, że musisz używać Reduxa.
Natomiast w dokumentacji samego Reduxa jest napisane, że nie trzeba go używać z Reactem, a można z czymkolwiek.
🤷♂️
To ma swoją nazwę
Te “pułapki”, o których piszę mają dwie nazwy.
Bardziej ogólna to po prostu dogmatyczne myślenie. Myślenie bez sprawdzenia, czy to w co wierzymy ma w ogóle sens.
Bardziej konkretna to cargo cult programming.
Wikipedia całkiem dobrze daje radę z opisem.
W skrócie, “cargo cult” odnosi się do takiego zjawiska, że kiedyś grupa ziomeczków, którzy mieszkali na wyspach i których największym wynalazkiem był ogień oraz zaostrzone patyki, zobaczyli jak na ich “podwórku” lądują samoloty z zaopatrzeniem np. podczas II Wojny Światowej.
Zaczęli więc budować własne “pasy startowe” bo myśleli, że wtedy przylecą samoloty, utożsamiane przez nich z boską interwencją i przyniosą im skrzynki z żywnością itp.
“Cargo cult programming” to jest to samo zjawisko. “Użyję wzorca i wtedy, dzięki jakiejś magii, moja apka będzie zajebista” <3.
Gdy nie uwżasz na te pułapki, to zaczynasz dobierać złe rozwiązania, marnować czas, marnować pieniądze i niepotrzebnie komplikować kod.
Ci goście z wysp mogli pewnie zrobić kilka udanych polowań na zwierzynę, zamiast budować pasy startowe, na których nic nigdy nie wyląduje.
A najgorsze z tego wszystkiego jest to, że gdy nie weryfikujesz wiedzy, którą zdobywasz, to automatycznie hamujesz swój rozwój.
Używasz narzędzi, których nie rozumiesz, nie używasz ich tak, jak trzeba i krążysz po omacku jak dziecko zagubione w ciemnym lesie. Sad but true.
Co możesz z tym zrobić?
1. Włącz swój bullshit detector
A gdy go już włączysz to uczul go na zdania “bo tak się robi” i “bo zawsze tak robiliśmy”.
Te dwa piękne zdania to nie jest wystarczający powód.
Gdy ja je słszę, to mam ochotę odstrzelić komuś łeb. Czasem musiałbym ten łeb odstrzelić samemu sobie 😄.
Dogmatyczne myślenie to pułapka, w którą możesz wpaść niezależnie od doświadczenia i stanu wiedzy.
Każda “dobra praktyka” powstała z jakiegoś powodu i rozwiązuje jakiś konkretny zestaw problemów. Niekoniecznie Twoich problemów.
Dlatego nie możesz ślepo podążać za trendami i wzorcami nie rozumiejąc, w jakich kontekstach należy je stosować.
2. Zadawaj pytanie “dlaczego?” znacznie częściej
- Dlaczego używamy tego frameworka lub biblioteki?
- Dlaczego używamy tego wzorca?
- Dlaczego używamy tej bazy danych?
- Dlaczego musimy robić to teraz?
Te pytania wymusząją zrozumienie przeznaczenia wszystkich narzędzi, których używasz.
Gdy zrozumiesz, jakie są zastosowania Reduxa, to pojmiesz, dlaczego wcale nie jest wymagany do pracy z Reactem. I że może podążałeś za czyjąś opinią, która w głębi duszy Cię męczyła, a nie wiedziałeś, że wcale nie musisz.
W dobrych zespołach programistycznych ludzie nawzajem kwestionują swoje wybory. Wiedzą, że tylko w taki sposób mogą weryfikować, czy nie podejmują jakiejś głupiej decyzji. Nie boją się pytać “dlaczego?“.
W jednym z poprzednich wpisów pisałem już o tym, że zadawanie pytań, to jeden z lepszych sposobów, żeby wykazać się w projekcie.
Dlatego, gdy następnym razem usłyszysz “bo tak się robi” albo “bo tak zawsze robiliśmy”, to przyciśnij typa i wyduś z niego, o co naprawdę chodzi. Zapytaj, dlaczego tak się robi.
Jeśli odpowiedzią będzie “bo zawsze tak robiliśmy”, to na bank “robiliśmy tak” z jakiegoś konkretnego powodu. Gdy ten powód ma sens w obecnym momencie to problem solved. Jeśli nie, to gratulacje, właśnie uniknąłeś mega niebezpiecznej pułapki 👏. Masz szanse przemyśleć swoje zachowanie :D.
Skupiaj się na faktach i dobieraj rozwiązania bazując na problemach, które masz teraz, a nie takich, które ktoś miał kiedyś w przeszłości.
Wiadomo, trzeba korzystać z doświadczenia swojego i innych, ale upewnij się, że te doświadczenia mają sens w Twoim kontekście.
Wiem, że się powtarzam i robię to z premedytacją.
Ja ciągle pytam “dlaczego?“. Myślę nawet, że niektórzy mnie za to nie lubią.
Głównie dlatego, że muszą się wysilić i coś wyjaśnić. Wyjaśnienie czegoś jest problemem, gdy jedyną podkładką jest to, że ktoś kogo szanują, kiedyś im powiedział, że tak się robi.
Bo Netflix tak robi. Bo na YouTube widziałem. Bo na Fejsie tak mówią. Bo mama mnie tak nauczyła. Bo “tata, a Marcin powiedział”.
Dla tych co nie znają lub nie mogą pamiętać, że telewizory kiedyś były kwadratowe i miały 15 cali:
Tata, a Marcin powiedział – polski serial telewizyjny emitowany przez TVP1 od 15 października 1993 do 7 stycznia 2000, wyreżyserowany przez Wojciecha Adamczyka.
Kilkuminutowe odcinki mają formę dialogu pomiędzy ojcem (w tej roli: Piotr Fronczewski) i dorastającym synem (Mikołaj Radwan), zaczynającego się od słów “Tata, a Marcin powiedział, że jego tata powiedział…“.
~Wikipedia
Mam kolegę w zespole, który ma bardzo mocno wyczulony bullshit detector i często zadaje mi to trudne pytanie - “dlaczego”.
Trochę się gotuję w środku, gdy nie mam gotowej odpowiedzi, ale niesamowicie to uwielbiam. Wiem, że dzięki temu ograniczamy ilość bezsensownych rozwiązań w projekcie, a przy okazji wypracowujemy wspólnie rozwiązania i dzielimy się wiedzą.
Dobry programista nie boi się pytać “dlaczego?”, bo dzięki temu stoi na straży i się rozwija.
Parting words
Jest duża szansa, że jeśli mocniej zastanowisz się nad pułapką dogmatycznego myślenia, to na czas nieokreślony zrujnujesz sobie życie i będziesz żył w strachu.
Będziesz zastanawiał się tak jak ja, kiedy piszę każdy nowy wpis, czy czasem nie ciśniesz głupot i czy zaraz ktoś Ci nie wytknie, że “cargo cult”, czy coś.
Z góry przepraszam. Choć uważam, że lepiej wiedzieć :D. Po to mam na blogu sekcje komentarzy - żebyśmy mogli sobie wyjaśnić wszystkie nieścisłości. Już nieraz ktoś mnie poprawiał i musiałem doprecyzować albo zmieniać zdanie.
Na tym to wszystko polega. Negatywny feedback najszybciej przyspiesza rozwój.
Trzeba tylko pogodzić się z tym, że nie zawsze mamy rację i że nie raz ktoś nam to bardzo dobitnie wytknie. Lepiej przygotować się na to już teraz.
Tym samym zapraszam do wytykania wszystkich błędów i nieścisłości w moim myśleniu. Oraz oczywiście, pytań typu “dlaczego”.
Cheers 🖖
ps. Założyłem stronę na fejsie dla bloga. Jeśli korzystasz z niego do zbierania newsów to łap linka.