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.