DRY – KISS – YAGNI, czyli jak „doświadczeni” programiści zapominają o podstawach.

|

DRY – KISS – YAGNI.

Tak, tak – wszyscy programiści uwielbiają chwytliwe akronimy. Ten podziw rośnie przeważnie wraz ze stażem pracy. Z zastosowaniem reklamowanych zasad w praktyce bywa jednak bardzo różnie.

Okazuje się, że im prostsza reguła, tym trudniej ją zachować – naprawdę niesamowita sprawa. To jest właśnie to, co odróżnia doświadczenie od stażu pracy.

Co to oznacza ? Dokładnie tyle, że stosując kilka podstawowych zasad oraz ogólnie przyjętych norm w praktyce, z automatu trafiasz do czołówki. Weźmy pod uwagę tytułowe trio, czyli absolutny fundament.

Don’t Repeat Yourself.

Jeden z grzechów głównych – powtórzenia w kodzie źródłowym. Każdy programista powinien zauważać takie sytuacje niemal natychmiast – i sprawnie sobie z nimi radzić. Każde uczucie deja vu powinno powodować natychmiastową reakcję – przynajmniej zatrzymanie się na chwilę i rozpoznanie sytuacji.

Jak likwidować powtórzenia ? To proste. Prawie zawsze dobrym rozwiązaniem jest nowa funkcja. Tworzysz nową funkcję, kopiujesz do niej powtarzający się kod, a w miejscach powtórzeń wywołujesz utworzoną funcję. Tyle.

Tym jednym ruchem: skracamy kod źródłowy, ułatwiamy jego zrozumienie, umożliwiamy jego testowanie oraz dajemy możliwość łatwego wprowadzania zmian w przyszłości. Tak wiele za tak niewiele.

Keep It Simple Stupid.

Kod powinien być tak prosty, jak to tylko możliwe. Co prawda likwidacja muchy za pomocą armaty może być widowiskowa, ale później i tak trzeba będzie posprzątać. Niepotrzebnie skomplikowany kod ma same wady – brak czytelności, brak zrozumienia, brak sensu.

Programiści uwielbiają się popisywać. Trzeba jednak wiedzieć, gdzie, kiedy i jak pokazać swoje umiejętności. Komplikowanie kodu bez celu przyniesie efekt odwrotny do zamierzonego.

Chcesz być profesjonalistą ? Twórz prosty kod.

You Aren’t Gonna Need It.

Co należy robić z kodem, którego nie potrzebujesz ? Bezwzględnie go usuwać. Nie przekształcać w komentarz, bo „może się potem przyda”. Jeśli będzie potrzebny, można będzie do niego wrocić, bo przecież korzystasz z systemu kontroli wersji (prawda ?).

Druga uwaga jest taka, że należy unikać bezsensownego dodawania zależności do naszego kodu. Wiąże się to z poprzednim punktem, mówiącym o prostocie. Dołączanie do projektu wielkiej, zewnętrznej biblioteki lub frameworka tylko po to, żeby użyć jednej klasy lub funkcji w naszym kodzie nie jest „spoko, bo nie trzeba tego implementować”…

Jeśli funkcjonalność nie jest skomplikowana, możemy zaimplementować ją w krótkim czasie samodzielnie. Możesz też skorzystać z innych kilku(nastu/dziesięciu) gotowych rozwiązań, które są modularne, mają sensowną licencję i nie zaimportują nam przy okazji tysięcy niepotrzebnych linii kodu.

Nowo dodawany kod powinien robić dokładnie to, co w danej chwili mówią wymagania. Pisanie kolejnych linii „na zapas”, bo w przyszłości „na pewno” się przydadzą, jest dość naiwne. Nie marnuj czasu na rzeczy niepotrzebne, które będą wymagały utrzymania – być może ten kod już nigdy się nie zmieni. Nie oznacza to oczywiście przeginania w drugą stronę – po prostu dopasuj elastyczność i prostotę do obecnej sytuacji.

Dlaczego to takie trudne ?

Nawet programiści z długoletnim stażem pracy potrafią pisać niechlujny, przesadnie skomplikowany, zastawiony pułapkami kod – albo od niechcenia, albo z lenistwa, albo dla zabawy. Powód nie ma znaczenia. Liczba lat pracy lub poznanych bibliotek i frameworków przestaje mieć znaczenie. To nie są profesjonaliści.

Profesjonaliści piszą dobrze ustrukturyzowany, prosty i zrozumiały kod. Robią to, co do nich należy.

W której grupie chciałbyś się znaleźć ? Z kim chciałbyś pracować ? Kogo powinienieś zatrudniać ?

To proste.

Wyłania się z tego tylko jeden, sensowny podział: programiści kontra klepaczeprofesjonaliści kontra amatorzy.

5 komentarzy do “DRY – KISS – YAGNI, czyli jak „doświadczeni” programiści zapominają o podstawach.”

  1. Wiem, że minęły prawie dwa lata od tego wpisu, ale aż dziwne, że nikt nie pozostawił takiego komentarza:

    YAGNI nie polega na tym, że wyrzucamy niepotrzebny kod lub nie importujemy nowych zależności! YAGNI mówi o tym, żeby nadmiernie nie kombinować i nie starać się pisać „elastycznego” kodu, który przewidzi wszystko, bo i tak wszystkiego nie przewidzimy, a z połowy „zabawek” potem nawet nie skorzystamy. Mamy na chwilę obecną wymagania X => piszemy kod pod wymagania X, nie pod XX ani pod X2… Przyjdzie czas na inne warianty gdy przyjdzie czas. Teraz zrób dobry kod, który będzie obsługiwał obecne wymagania.

    Odpowiedz
    • Wszystkie te rzeczy łączą się ze sobą, ale faktycznie podrozdział nie oddawał w pełni tego, co powinno zostać powiedziane o YAGNI. Dodałem do podrozdziału dodatkowy akapit. Dzięki za komentarz 🙂

  2. No ale w drugą stronę też można przegiąć, zwłaszcza jeżeli wymagania zbiera ktoś niekumaty. Nie piszesz pod wymaganie Y bo nie potrzebne…. a za tydzień się okazuje potrzebne, co można było ustalić wcześniej zadając pytanie. Debile z marketingu uwielbiają w taki sposób ułatwiać pracę programistom i nie da się ich przekonać że tak naprawdę ją utrudniają

    Odpowiedz
    • To trzeba było takie pytanie zadać…a nie, zapomniałem, że dev nie musi się interesować takimi drobiazgami i orientować się, co tak właściwie robi. Ważne, żeby było YAGNI, SOLID, itd. i żeby później można było batożyć „debili” z marketingu, sprzedaży, managementu.

Dodaj komentarz