Clean code? Nie dziękuję.
Przestańmy korzystać z określenia czysty jako przymiotnik do kodu. Jak słyszę clean code to zaczyna mną telepać – to sformułowanie powinno zostać zakazane w środowisku IT. W świecie programowania nastała moda na używanie tego określenia, a w zasadzie problem zaczyna powoli przypominać religię. Nastała tendencja do utrudniania sobie życia np. poprzez wprowadzanie dodatkowych abstrakcji tam gdzie nie potrzeba, zakazywanie niektórych wzorców, czy dążenie do całkowitego „niepowtarzania kodu”.
Pytanie co to w ogóle jest clean code? Według Wiktionary definicja clean code jest następująca: „Non-redundant software code comprising of focussed task-specific modules and functions, written in a systematic manner so that another coder can easily interpret or modify it”. Ta definicja jest dość abstrakcyjna i raczej nie można wyciągnąć z niej jednoznacznych wniosków dotyczących tego, jakie (globalne) standardy ma posiadać oprogramowanie. Te słowa można interpretować na wiele sposobów.
Początkujący programiści często popadają w pułapkę „czystego kodu”. Na bootcampach, czy filmikach na youtube/udemy poznają czyjąś wersję clean code. Często to są głupoty, które w rzeczywistym świecie tworzenia oprogramowania nie mają sensu. Ci adepci programowania zaczynają traktować dogmaty clean code jako prawdę absolutną, gdzie jakiekolwiek odstępstwa są niedopuszczalne.
Często ten problem zaczyna się na początku nauki. Nierzadko jest tak, że treści edukacyjne (na youtube/udemy) są tworzone przez mało doświadczonych programistów, w tym tutoriale dotyczące „czystego kodu”. Bardzo ciężko znaleźć materiały tworzone przez profesjonalistów i dlatego łatwo wpaść w pułapkę indoktryny clean code.
Jeden z gorszych nawyków wpajanych przez patoclean coderów, to podział kodu na jak najmniejsze funkcje. Widziałem wiele MRek gdzie juniorki podążając za tą zasadą, napisały algorytm, który nie podzielony zajmuje 5 linijek, a po ich przetworzeniu każda linijka dostała przypisaną do siebie funkcje, mało znaczącą nazwę tej funkcji. Później czytając implementacje algorytmu, konsument musi skakać z funkcji do funkcji z redundantnymi summary. Kończy się na tym, że algorytm 5 linijkowy jest zapisany w 50 linijkach (o ile juniorek nie porozbija tego na pare plików i doda do tego jeszcze jakiś interfejs, bo wiadomo abstrakcje fajne). Oczywiście zgadzam się, że podział na funkcje/metody jest ważny i potrzebny, ale trzeba mieć do tego wyczucie i zachowywać balans pomiędzy czytelnością i granulacją.
Podobnie sytuacja wypada w przypadku podziału na wiele plików.
Dla niektórych czysty kod to taki, gdzie każdy typ umieszczony jest w osobnym pliku.
Osobiście, również dzielę projekt na wiele plików, ale należy przy tym pamiętać o robieniu tego z umiarem.
Znowu podział na wiele małych plików sprowadza się do porządku lokalnego, ale często może prowadzić do bałaganu globalnego.
Róbmy to z rozsądkiem.
Warto tutaj zwrócić uwagę, dla przykładu w języku C++, często spotkać się można z tzw. header only libs, gdzie cały projekt zamieszczony jest w pojedynczym pliku.
Nikt im nie robi wrzut, że czyściej byłoby podzielić pakiet na małe pliki.
Wiele osób z clean code bezpośrednio kojarzy wzorce projektowe, tzw. design patterns. Design patterny, kiedy są nadużywane lub używane źle, mogą być objawem choroby clean code. To samo dotyczy bezpośrednio wzorców projektowych. Weźmy np. singleton, przez wielu postrzegany jako antypatern, który można wyeliminować. To samo dotyczy wszelkiego rodzaju globalnych/statycznych obiektów. Zgadzam się, że w większości przypadków używanie singletonu to zły pomysł, ale istnieje też wiele sytuacji, kiedy singleton może okazać się niesamowicie przydatny i może się okazać najlepszym rozwiązaniem danego problemu. Podkreślam, użycie przymiotnika „najlepszym”, nie „najczystszym”. Nie wiem w jaki sposób można zmierzyć czystość wykorzystania singletona w danym projekcie.
Wiele osób kojarzy „clean code” z pewnymi zasadami typu SOLID, DRY, GRASP, KISS, YAGNI, itd. Nie twierdzę, że te zasady są złe, a jedynie stwierdzam fakt, że te zasady nie są prawdą absolutną, są jedynie wskazówkami podczas tworzenia oprogramowania. Są szczególnie istotne podczas nauki, gdzie można dowiedzieć się czego warto unikać, ale nie są tak bardzo istotne w życiu codziennym programisty. W normalnej współpracy, współpracownicy podczas review nie powinni wytykać „tutaj złamana zasada D z SOLID, tutaj piszemy tylko czysty kod”. Kolejny raz określenie „czysty” nie ma najmniejszego sensu. Jakbyśmy zrobili eksperyment myślowy, przygotowali „brudny” kod do recenzji i jako recenzentów wzięlibyśmy programistów z odpowiednio programowania funkcyjnego, obiektowego czy data oriented zaobserwowalibyśmy na pewno ciekawy pojedynek. Ciekawi mnie, czy zaczęły by się dyskusje o „czystość” rozwiązania. Ten eksperyment pięknie pokazuje, dlaczego nie powinniśmy używać określenia „czysty kod”.
Wracając do zasady DRY, ta zasada wymaga szczególnego komentarza. „Czysto pisarze” mają tutaj tendencję do nadużywania tej zasady. Tu nie chodzi o to, żeby w projekcie nie było żadnych powtórzeń. I kolejny raz natrafimy na kwiatki podczas review: „wynieś to do statycznego utilsa, będzie czyściej”. Pojawia się pytanie ile razy wykorzystamy tego utilsa? Teraz pojawia się problem, że staramy się sprzątać projekt lokalnie i to sprzątanie prowadzi do bałaganu globalnego w projekcie.
Mam wrażenie, że często wyznawcy „clean code” prześcigają się kto zrobi „czystszy kod”. To prowadzi do absurdalnych rozwiązań, a w zasadzie do marnowania czasu i potencjału. Ile pożytecznych funkcjonalności można by przygotować za ten zmarnowany czas na „doskonalenie doskonałości”. Na GitHub można znaleźć perełki gdzie użytkownicy przygotowują parodię takiego podejścia. Świetny przykład można znaleźć tutaj [1].
Jednak wydaje mi się, że największym problemem patoclean coderów jest podeście do „czystego” nazywania rzeczy (typów, zmiennych, metod, itd.).
Nazewnictwo jest ekstremalnie ważne podczas tworzenia oprogramowania.
Jednak niektórych cechuje ekstremizm do tworzenia nazw które są zbyt verbose, co prowadzi do takich patusów jak: GetCountriesFromAsiaWhereAreTheMostPlanesAndBoats.
Założeniem autora, nazwa miała być clean, tłumacząca wszystko co robi dana metoda.
To można skomentować jednym zdaniem: to jest po prostu do dupy.
Problem długich nazw można rozwiązać odpowiednią „architekturą”, albo odpowiednio udokumentować kod.
Absurdem jest też opinia niektórych programersów, że zmiennej do indeksowania w pętli nie można nazywać symbolami i,j,k, tylko trzeba używać bardziej verbose typu index.
Kolejnym problemem jest twierdzenie, że czysty kod nie posiada komentarzy, że nazewnictwo i stylistyka jest samodokumentującym się bytem. To jest prawdopodobnie źródłem tych bydlastych nazw z poprzedniego akapitu. Projekty potrzebują dokumentacji i komentarzy. Większość programistów nie wie, czym różni się dokumentacja od komentarzy. Osobiście uważam, że nadmiarowe komentarze są złą praktyką. Wstawiam komentarze wtedy, kiedy coś jest potrzebne do sprecyzowania (np. w czym wyrażony jest dany parametr radiany, czy stopnie) lub kiedy chce opisać co się dzieje w „skomplikowanym”, czy hackowatym kodzie.
Niektórzy twierdzą, że czysty kod powinno móc się wydrukować i czytając ktoś będzie wiedział co ten kod robi. To jest jedna z głupszych opinii jakie słyszałem. Żyjemy w XXI wieku. IDE to podstawowe narzędzie programisty. Nie da się wykonać efektywnie porządnego review w przeglądarce internetowej. Checkoutujcie i reviewujcie w narzędziach z których korzystacie.
Odnoszę wrażenie, że część ludzi traktuje tworzenie oprogramowania jak sztukę, stąd nawiązanie do zwrotu „czysty kod”. W mojej opinii jest to całkowicie błędne stwierdzenie. Dla mnie pisanie kodu to bardziej rzemiosło, porównałbym to bardziej do wykończeniówki czy do budowlanki, a nie artysty malującego obraz. Kod ma działać, ma być funkcjonalny, łatwy w modyfikacji. Na pewno nie powinniśmy mierzyć jakości kodu jego „pięknem”.
Osobiście podczas pisania programów wyznaję zasadę „the simpler, the better”. W większości przypadków to się sprawdza. Należy tutaj podkreślić, że powinno się utrzymywać odpowiedni balans pomiędzy powtórzeniami kodu i prostotą. Kończąc ten artykulik chciałbym do Ciebie zaapelować: nie używaj zwrotu „clean code” do określania jakości oprogramowania. Jak robisz komuś review i zauważysz rozwiązanie, które Twoim zdaniem nie jest najlepszym podejściem w tej sytuacji napisz: „uważam, że w tym przypadku lepszym rozwiązaniem byłoby zastosowanie X a nie Y”. Opisana opinia związana z czystym kodem nie należy tylko do mnie. Tutaj możesz znaleźć podobne zdanie w tej kwestii [2].
Bibliografia
- EnterpriseQualityCoding/FizzBuzzEnterpriseEdition, GitHub repository (2025). ↩
- Steve On Stuff blog, There’s No Such Thing as Clean Code (2022). ↩