Czym tak naprawdę jest “zły kod”? Każdy z nas go widział, każdy z nas potrafi go rozpoznać…
Ale czy każdy z nas potrafi powiedzieć co to dokładnie znaczy “zły kod”?
Jak rozpoznać zły kod?
To proste! Wystarczy, że jest nieczytelny…
Ok, a czytelny kod który działa niepoprawnie?
No, raczej też jest zły… w końcu nie działa
A kod który jest czytelny i poprawny, ale działa wolno lub zajmuje dużo pamięci?
No, to częściowo zły bym powiedział…
A jak jest skomplikowany?
To chyba zależy. Czasami bywa, że rozwiązanie problemu jest skomplikowane, więc i kod taki sam jest…
Ciężko powiedzieć…
I tak dalej, i tak dalej…
Definicja
Ciężko jest dokładnie zdefiniować termin “zły kod”.
Ilość czynników wpływających na stan kodu jest po prostu zbyt duża…
Zastosujemy zatem staro-polsko-matematyczne przysłowie:
Niechaj waćpanowi, bądź waćpannie, przypatoczy się problem z tabunem zmiennych powiązany – Dowód nie wprost! Zawżdy powinien być wysnuty.
Dobry kod
Spróbujmy więc zdefiniować czym jest “dobry kod”.
Posłużymy się czterema zasadami Kenta Becka:
Poprawnie przechodzi testy
Nie zawiera powtórzeń
Obrazuje zamysł programistów
Minimalizuje ilość elementów
Poprawnie przechodzi testy
Testy? Przecież kod nie musi mieć testów aby być dobry… prawda?
Może sparafrazuje ten punkt:
Poprawnie wykonuje powierzone mu zadanie, zawiera mechanizm sprawdzający czy to zadanie jest poprawnie wykonywane oraz owe zadanie jest odpowiednio udokumentowane
I to wszystko za pomocą testów?
Nawet i więcej. Ale to temat na kiedy indziej…
Skupmy się na razie na tym, że wykonuje swoje zadanie poprawnie.
Nie zawiera powtórzeń
Brzmi całkiem sensownie…
Yup, tutaj nie ma żadnych haczyków.
Obrazuje zamysł programistów
Innymi słowy – jest czytelny.
Minimalizuje ilość elementów
Elementów? W sensie klas i metod? To znaczy, że lepiej jest zrobić jedną dużą klasę?
Nieeee, nie w tym rzecz.
Jeżeli zrobisz wszystko w jednej metodzie/klasie, to powstanie cała masa zduplikowanego kodu.
To w czym rzecz?
Aby nie pisać zbędnego kodu – czyli nie pisać wymyślnych frameworków do prostej funkcjonalności.
Innymi słowy: im prościej – tym lepiej.
Okej, to powiedz mi teraz która z tych reguł jest najważniejsza?
Ha – i tu mnie masz.
Subiektywna kolejność
O ile z samymi zasadami (w sumie raczej radami bym je nazwał) większość programistów się zgodzi…
To już z kolejnością bywa różnie.
Przedstawię za to moją kolejność:
Testy
Czytelność
Brak duplikatów
Zwięzłość
Zły kod – tak naprawdę
Dobra dobra, to jak to się wszystko ma do złego kodu?
Zły kod to taki, który nie spełnia zasad wymienionych powyżej.
Hmm, czyli czytelny i prosty kod, ale za to z duplikatami to zły kod?
Tak – chociaż nie całkiem…
Widzisz Januszu, stan kodu nie jest binarny – albo zły albo dobry.
Zobrazujmy to sobie:
WTFs per Minute
Aha, czyli sugerujesz, że nie ma kodu idealnego?
Nie ma również kodu który jest całkowicie zły…
To jest w ogóle jakiś sens w zastanawianiu się nad tym?
Dobre pytanie! Otóż jest… lecz najpierw musimy się dowiedzieć czy dobry kod w ogóle ma sens.
Be First to Comment