bookmark_borderProblem nazw w programowaniu

Czytanie kodu źródłowego jest trudniejsze, niż jego pisanie. Przyzna to każdy kto pracował z odziedziczonym repozytorium i próbował zrozumieć jego działanie. Przebijanie się przez tysiące linii kodu, przez setki definicji funkcji i zmiennych, w próbie zrozumienia co autorzy mieli na myśli jest ciężkim, męczącym, okrutnie wyczerpującym zadaniem.

Dlaczego tak jest?

Czy zrozumienie przepisu kuchennego jest trudne?

Czy jest trudniejsze od napisania go?

Czy zrozumienie przepisu kuchennego sprzed trzydziestu lat jest trudniejsze od zrozumienia przepisu sprzed tygodnia?

Nie sądzę.

Czemu więc czytanie kodu źródłowego staje się trudniejsze z każdym kolejnym miesiącem od jego powstania? Dlaczego nowy kod jest czytelny, a stary niezrozumiały? Jaka może być przyczyną „gnicia oprogramowania” i nienawiści do legacy code?

Zastanówmy się nad czynnością czytania kodu źródłowego. Co robimy próbując zrozumieć program, wgryźć się w kod?

Działamy jak komputery, tylko mniej wydajnie. Przeglądamy kod, czytamy go, napotykamy na zmienne i funkcje. Nie będąc maszynami nie jesteśmy w stanie spamiętać każdej wartości oraz ciągu konstrukcji. Próbujemy więc „zrozumieć” kod. Napotykając na nazwę zmiennej staramy się domyślić, co oznacza i w jakim kontekście jest używana. Nazwy funkcji lub procedur również próbujemy zrozumieć, najlepiej bez wnikania w ich treść.

Dokładnie tak samo działamy w świecie rzeczywistym. Gdy w przepisie napotykamy na słowo „marchew” wyobrażamy sobie marchew. Rozumiemy ideę marchewki bez zapoznawania się że szczegółami takimi jak jej masa, kolor, DNA, czy temperatura.

Kod źródłowy jednak – mimo starań obozu oprogramowania zorientowanego obiektowo – nie jest jak świat rzeczywisty. Odstaje od niego znacząco.

W świecie rzeczywistym dysponujemy ogromną, lecz ograniczoną ilością słów w naszych słownikach. Języki naturalne przetwarzane są przez ludzkie mózgi zupełnie inaczej niż kod źródłowy przez kompilatory. Krzesło na przykład to dla człowieka nie tylko konkretne krzesło, ale idea krzesła jako takiego. W większości przypadków zbędne nam są szczegółowe informacje na temat obiektów by przetwarzać i rozumieć język naturalny, w którego zdaniach te obiekty, reprezentowane przez słowa, występują. Tam z kolei gdzie jest nam potrzebna precyzja definicji (jak w prawie na przykład) napotykamy na spore problemy.

Świetnym przykładem ilustrującym, co by było gdybyśmy przetwarzali język naturalny tak jak komputery przetwarzają kod źródłowy jest ten filmik:

Wróćmy do czynności czytania kodu przez programistów. Cóż robi developer? Czyta nazwę zmiennej lub funkcji i próbuje zgadnąć, co ona oznacza. Póki kod jest „czysty” i niezbyt stary instynktowne zrozumienie jest stosunkowo poprawne. Czytanie idzie mu dobrze i praca z kodem jest sprawna.

Kłopot zaczyna się, gdy nie jest w stanie poprawnie domniemać znaczenia nazw.

Problem jest jednak znacznie poważniejszy. Jest to jedna z fundamentalnych trudności w rozwoju oprogramowania. Częściowo oddaje to poniższy cytat:

There are only two hard things in Computer Science: cache invalidation and naming things

Phil Karlton

Chodzi o nazewnictwo.

Nazewnictwo jest punktem styku pomiędzy światem maszyn i ludzi. Jest jednocześnie przepaścią między jednym, a drugim. W świecie rzeczywistym, gdzie język ludzki rozumiany jest przez mózgi, które są w stanie instynktownie zrozumieć klasy obiektów / idee przedmiotów rzadko tworzone są nowe słowa. W kodzie źródłowym nowe słowa tworzone są nieustannie.

Co dzieje się, gdy tworzymy nowe słowo w ludzkiej mowie? Uczymy się go. Powstaje nowe słowo – na przykład „komputer” – i wszyscy ludzie na świecie uczą się, że oznacza ono taką, a nie inną rzecz. Nie ma znaczenia, czy mowa o MacBooku, Dellu XPS, ENIACu, czy PC-cie. Nie tworzymy odrębnych słów opisujących komputery stojące w każdym z departamentów firmy, nie tworzymy innych słów na różne modele MacBooka mające inną wielkość pamięci RAM. Nie ma takiej potrzeby. Nowe słowa tworzymy rzadko. Za nowym słowem kryją się duże grupy obiektów. 

Inaczej jest w przypadku kodu źródłowego. „Użytkownik” znaczy co innego w każdym omal programie, jaki do tej pory napisano. W jednych jest to imię i nazwisko, w innych również data urodzenia, w jeszcze innych płeć. W niektórych imię i nazwisko może się składać tylko z liter łacińskich, w pewnych mieć maksymalnie 20 znaków. I tak dalej, etc.

Mówiąc krótko: w kodzie źródłowym niczego nie da się nazwać poprawnie. Żadna nazwa, jak dobrej byśmy nie wybrali, nie będzie odpowiadała znaczeniu słów wyjętych z języka naturalnego, ze świata ludzi.

Możemy być tylko zbyt precyzyjni („user”) lub zbyt ogólni („userWithNameAndSurnameAndSexAndDateOfBirth). Nigdy omal nie będziemy idealnie precyzyjni w nazywaniu zmiennych, czy funkcji. Nigdy te nazwy nie będą znaczyły tego, co nam się wydaje. Zawsze musimy nawigować się do definicji i czytać implementację. Za każdym razem, gdy dołączamy do istniejącego projektu musimy „nauczyć się jego języka”. Nauka nowego języka jest zawsze trudna, żmudna i męcząca. Dlatego właśnie, ze wszystkich wymienionych powyżej przyczyn, czytanie kodu źródłowego jest trudne.

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.

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.