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 klepacze – profesjonaliści kontra amatorzy.
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.
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 🙂
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ą
Temat rzeka 😀
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.