Pierwszy raz o pojęciu czysty kod dowiedziałem się przeglądając w księgarni książkę Czysty kod. Podręcznik dobrego programisty. Książka ta zrobiła na mnie wtedy pozytywne wrażenie, ponieważ była ona inna od wszystkich jakie dotychczas znałem.
To co wyróżniało tą pozycję, to poruszone w niej zagadnienia związane z jakością oprogramowania, a także cenne wskazówki dotyczące samego kodu.
Najbardziej zapadającą w pamięć wskazówką z książki był poniższy cytat:
Funkcje powinny wykonywać jedną operację. Powinny robić to dobrze. Powinny robić tylko to.
– Czysty Kod, Robert C. Martin
Początkowo nie zwracałem uwagi na narastającą złożoność, ponieważ w większości przypadków, kod który wydzieliłem mogłem łatwiej i dokładniej przetestować. Była to zasłużona nagroda za włożony trud.
Z perspektywy czasu widzę, że kładłem zbyt duży nacisk na rozbijanie kodu, podążając "ślepo" za założeniami jakie stały za czystym kodem.
Niestety, to co może wymknąć się spod kontroli pisząc czysty kod, to paradoksalnie utrata czytelności kodu. Porozbijany kod jest niemożliwy w czytaniu linia po linii jak opowiadanie. W pogoni za szczegółami trzeba skakać po plikach i łączyć wiele faktów, aby zrozumieć to za co odpowiada aktualny wybrany fragment kodu.
Ktoś może powiedzieć: Po to dzielę kod na funkcje/klasy, aby nie myśleć o szczegółach.
Problem w tym, że w przypadku biznesowego kodu, biznesowe szczegóły są istotne i próba ich ukrywania zwykle zawodzi, wywołując efekt odwrotny do zamierzonego. Innymi słowy, tworzenie abstrakcji z biznesowych szczegółów może okazać się nie do końca trafionym pomysłem.
Czyli jak widać założenia czystego kodu, nie zawsze się sprawdzają, ponieważ rozbijanie kodu może wpłynąć negatywnie na jego czytelność.
Warto dopuszczać do powtórzeń, a w rezultacie zwlekać z DRY. Dzięki temu możemy zredukować liczbę możliwych skoków w czytaniu, do tych niezbędnych w zrozumieniu rozpatrywanego kodu.
Zarówno podejście z czystym kodem, jak i podejście z tolerowaniem powtórzeń ma na celu ułatwienie pracy z oprogramowaniem. To pierwsze ułatwia modyfikowanie, ponieważ zmianę wprowadza się tylko w jednym miejscu, a powstały efekt ma szeroki zasiąg. Drugie podejście umożliwia skupienie całej uwagi na czytaniu i analizie kodu dostępnym w jednym miejscu.
W praktyce korzystam z obu podejść. Pisząc kod preferuję wydzielać te części kodu, które mają marginalną rolę i nie są związane bezpośrednio z biznesem.
Natomiast część biznesową piszę bez nacisku na wyodrębnianie. Wychodzę z założenia, że biznesowa logika do pewnego stopnia może i ma prawo się powtarzać.
