DRY – KISS – YAGNI.

Tak, tak – wszyscy programiści uwielbiają chwytliwe akronimy. Ten podziw rośnie przeważnie wraz ze stażem pracy. Co jednak zauważyłem parę miesięcy temu – z zastosowaniem reklamowanych zasad w praktyce bywa bardzo różnie.

Kolejna obserwacja jest taka, że im prostsza reguła, tym trudniej ją zachować – naprawdę niesamowita sprawa. To jest wg mnie 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 trafiacie 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 najlepszym rozwiązaniem jest nowa funkcja. Tworzymy nową funkcję, kopiujemy do niej powtarzający się kod, a w miejscach powtórzeń wywołujemy 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. Chcecie być profesjonalistami – piszcie prosty kod.

You Aren’t Gonna Need It.

Co należy robić z kodem, którego nie potrzebujemy ? 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ż korzystamy 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żemy 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.

Dlaczego to takie trudne ?

Nawet „programiści” z długoletnim stażem pracy potrafią pisać niechlujny, przesadnie skomplikowany, najeżony 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 chcielibyśmy się znaleźć ?

Z kim chcielibyśmy pracować ?

Kogo powinniśmy zatrudniać ?

To proste.

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