bookmark_borderDRY is dead

Reguła DRY jest obok YAGNI, SOLID, czy KISS jednym z najpopularniejszych akronimów pisanych wielkimi literami, które wypłynęły na sposób w jaki staramy się tworzyć oprogramowanie. Jest prosta, intuicyjna i przyswajana przez programistów na wczesnym etapie edukacji. Tyle, że zrodzona w zupełnie innych okolicznościach, niż te z którym dziś mamy do czynienia stała się martwa.

Jej truchło leży na środku sceny i zatruwa nas swoimi oparami.

Prosty pomysł

Nie jestem historykiem programowania i nie dysponuję pewnością co do genezy reguły DRY, ale wyobrażam sobie, że powstała w czasach programowania proceduralnego. W każdym razie proceduralnością pachnie, wręcz cuchnie.

Prosty to pomysł. Banalnie prosty. Mamy sobie kod. Kod należy organizować w procedury, czyli wycinać bloki kodu, które są używane wielokrotnie. Jeśli w jakimś bloku się powtarzamy, to działamy źle, powinniśmy wydzielić go i przekształcić w procedurę.

Ciągle mało

Od czasu programowania proceduralnego trochę się pozmieniało. Przede wszystkim nastąpiła wielka eksplozja paradygmatu obiektowego. Złożoność oprogramowania wzrosła. Biznes miał już swoje systemy automatyzujące księgowość, sumujące przychody, generujące raporty. Trzeba było pisać przeglądarki internetowe, komunikatory, systemy tradingowe dla giełd i snake’a na 3310. Poza ostatnim – były to coraz większe wyzwania.

Tyle tylko, że reguła DRY pasuje do programowania obiektowego jakby mniej. W zasadzie w ogóle nie pasuje, jak się dobrze zastanowić.

Co się dzieje, gdy próbujemy w obiektowym kodzie unikać powtarzania się? Pierwsze co przychodzi do głowy to dziedziczenie: piękny akademicki koncept, który załamał się pod ciężarem rzeczywistości. Pies się wabi, kot ma imię, zróbmy klasę zwierzę. Zrobiliśmy. Szybko okazuje się, że pies się wabi, ale jednak imiona ma inne niż kot, że wabi się, ale kot jakoś gorzej reaguje na własne imię, że zwierzę ma imię, ale nie do końca, bo tylko zwierzę domowe. Robimy klasę zwierzę domowe i dzikie. O cholera – przecież prawie nikt nie nazywa swoich rybek.

Drugie popularne rozwiązanie to żartobliwa oznaka senior developera. Co robi senior developer, gdy przychodzi do chaotycznego projektu? Tworzy folder utils.

Klasy gromadzące wspólne, niepasujące nigdzie indziej kawałki kodu znajdują się obecnie w większości projektów. W niektórych z nich widziałem nawet rozrosłe do 8-16 tysięcy linijek „commony”. Tych polipów da się uniknąć i tak naprawdę powinny zostać rozmasowane z głową na różne fragmenty projektu, ale ich głównym źródłem jest próba stosowania reguły DRY – wydzielenia gdzieś, gdziekolwiek, bo tak najłatwiej, kodu, który się powtarza.

Mikroserwisy – gwóźdź do trumny

Kiedy zapytałem kolegi, który odszedł z Amazona – firmy, która traktowana jest jako modelowa i pionierska, jeśli chodzi o stosowanie architektury mikroserwisów – jak organizują części wspólne, skąd wiedzą, że inny zespół nie napisał już czegoś podobnego, odparł:

 Nie szukamy. Piszemy swoje rozwiązanie. Przy tej skali jest to tańsze i szybsze.

Skala, ogrom systemów, z jakimi przychodzi nam się dzisiaj mierzyć sprawia, że konieczne staje się dzielenie ich na mniejsze. W zasadzie od zawsze było to jedną z podstaw programowania, ale w architekturze mikroserwisów oraz komponentowym podejściu do aplikacji webowych (Angular, React) trend ten uwyraźnia się i przybiera na sile.

I w gruncie rzeczy jest to dużo bardziej obiektowe oraz zgodne z naturą, niż dziedziczenie. Organizmy są do siebie podobne, ale ciężko powiedzieć, żeby były takie same. Oko człowieka nie jest tym samym okiem, co oko psa, czy sokoła. Tylko z pozoru i powierzchownie można zakładać, że jest możliwe współdzielenie. Nie jestem ekspertem z dziedziny genetyki, ale nie wydaje mi się, że gdyby wyciąć z człowieka fragmenty DNA, których nie współdzieli z małpą stałby się automatycznie orangutanem. Silne jest we mnie podejrzenie, że choć wiele w tym podobieństw, czy identycznych fragmentów kodu, to jednak subtelności, kilka „linijek” różnicy sprawia, że dziedziczenie trzeba wziąć w duży, znaczący cudzysłów.

Jak żyć?

Wygląda na to, że reguła DRY dobrymi intencjami wybrukowała nam piekiełko. Czy czas ją odrzucić? Być może. Na pewno warto ją jednak przemyśleć. Warto pamiętać, że w wielu scenariuszach nie powinna być dla nas rekomendacją, że nie jest uniwersalnym narzędziem. Powtarzalność kodu może sygnalizować problemy, a równie dobrze może być najlepszym możliwym rozwiązaniem.

Czy dwukrotne powtórzenie identycznego kodu jest złe? Jeśli w tej samej klasie, pewnie jest. Jeśli w tym samym module, być może. A jeśli w projekcie składającym się ze 100 000 linii kodu, w odległych od siebie modułach? Chyba nie.

Czy częściowe powtórzenie kodu jest złe? Cóż, może nie jest złe arbitralnie, a zależy to od tego, czy da się zbudować odpowiednią abstrakcję, która pozwoli tego uniknąć? Często stosujemy pewne zasady ortodoksyjnie. Dobrze jest jednak zostać centrystą. Wybrać złoty środek. Reguły w programowaniu to zwykle zaledwie sugestie. Nie kierujmy się nimi ślepo.

Please follow and like us:

bookmark_borderStare spaghetti, czysta wódka i wujek Zdzisiek

Ktoś mnie ostatnio nazwał clean code evangelist. Pomyślałem – tytuł zobowiązuje. Trzeba napisać o czystym kodzie.

Co jednak napisać? Wszystko już było. Nic nowego pod słońcem. Krótkie metody, znaczące nazwy i ogólnie takie, takie. Co mógłbym ja, prosty programista, napisać o czystym kodzie pod koniec drugiej dekady XXI wieku? Dekady jaśniejącej tysiącem frameworków JavaScriptowych, dziesięciolecia mikroserwisów, chmury i dev-ops!

Metafory. Metafory zawsze służyły ludzkości. Horacy, Nostradamus, Popek. Wszyscy oni używali mglistego języka przenośni, by oddać esencję. Spróbujmy.

Spaghetti jest dobre, spaghetti smaczne jest, świeże spaghetti jest jak listek bazylii na pizzy, jak zapach wydechu Fiata w wąskiej uliczce Turynu, jak szynka parmezańska obsypana rukolą. Wszyscy lubimy gotować spaghetti. 8 minut i gotowe. Cottura 8 minuti i włala.

Kod spaghetti jest taki sam. Świeżo przygotowany pachnie soczystymi kaskadami ledwie widocznych zależności. Ma smak długich jak przedrelease’owe wieczory metod z posmakiem enigmatycznych nazw zmiennych, nazw dojrzewających w pełnym słońcu wschodzącego deadline’u.

Niestety, spaghetti nieskonsumowane przekształca się w to samo mniej więcej, co skonsumowane.

Spaghetti dojrzałe powoduje zaparcia, bóle głowy, a nawet rozwolnienia. Kod spaghetti tak samo – przydatny jest do spożycia w krótkim jedynie terminie.

Zastanawiając się, jaki pseudonim musiałbym sobie wybrać by zostać polskim Uncle Bob’em doszedłem do wniosku, że mógłbym być wujkiem Zdziśkiem. Na potrzeby tego i kolejnych akapitów – zostanę nim.

Posłuchajcie wujka. Wujek życie zna. Wujek pracował nad jednym projektem do emerytury w zakładzie pracy państwowym, nad projektem rządowym i wujek wie co to znaczy nieświeże spaghetti.

Rada wujka: kod ma być jak wódka.

Tak. Jak wódka ma być!

Wódka, jaka jest, każdy widzi. Jak koledzy z zespołu kod wódkę zobaczą, to przysiądą się, zaczną delektować się kodem wódką, zadowoleni będą, radośni. Kod wódka doskonale się integruje. Kod wódka nie ma zależności – można z ogórkiem, można z colą, wszystko co interfejs zakąska implementuje być może. Kod wódka powoduje najmniejszego kaca, o ile potrafimy go okiełznać.

Reasumując: kod ma być, jak wódka, czysty.

Tako rzecze wuj Zdzich.

Please follow and like us: