8 przyczyn złego kodu
Przyczyn powstawania brzydkiego kodu jest cała masa. Nie sposób wymienić wszystkich. Stworzyłem tę listę bazując na własnych obserwacjach. Są to elementy powtarzalne. Spotykane w różnych projektach dla różnych klientów. Dziele się nimi z Tobą. Bierz i korzystaj! Oto przyczyny złego kodu specjalnie dla Ciebie!
1. Nieprzemyślana architektura
Czy jesteś w stanie naszkicować, na kartce A4, architekturę systemu wraz z jego głównymi przepływami? Pomijając zbędne szczegóły. Jeżeli nie to jest ona zbyt skomplikowana lub nie ma jej wcale. Zastanów się nad tym.
2. Brak refaktoringu
Jak często refaktorujesz kod aplikacji, nad którą pracujesz? Raz na miesiąc/tydzień/dzień? Jedyna poprawna odpowiedź to “przy każdej możliwej okazji”. Tylko w taki sposób możesz zapewnić, że kod będzie zawsze czysty. Refaktoring to nic niezwykłego. Traktuj go jako normalną część pracy programisty. Tak jak to, że fachowiec, po sobie sprząta.
3. Zbyt duże klasy
Jest to najczęstszy błąd, jaki spotykam. Cały czas nie rozumiem dlaczego. Z jakiego powodu ludzie tworzą pliki po kilka tysięcy linii kodu? Tu nie ma co się rozpisywać. Weź to i podziel!
4. Nie dbanie o dobre nazwy
W programowaniu niewiele rzeczy jest tak trudnych, jak wymyślenie odpowiedniej nazwy. Niejednokrotnie zjada to więcej czasu niż implementacja. Gdy nie potrafisz wymyślić dobrej nazwy, to spójrz w bebechy i upewnij się, że nie ma tam zbyt dużo. Jeżeli wciąż Ci nic nie przychodzi do głowy, zostaw całe zdanie, a nie jeden wyraz. Przynajmniej będzie wiadomo, że jest coś nie tak.
5. Brak inspekcji kodu
Rzecz niby oczywista. Poproś kogoś, niech rzuci świeżym okiem na Twoje wypociny. Kiedy nie masz takiej osoby, nie zamykaj zadania wieczór. Zostaw je do następnego dnia. Rano przeczytaj jeszcze raz. Dzięki takiemu podejściu zagwarantujesz sobie, że kod będzie łatwiejszy do zrozumienia dla innych. Możesz też poprosić gumową kaczuszkę, by Cię wysłuchała :).
6. Nieczytanie kodu po napisaniu
Ile razy napisałeś kod, który działa, przeszedł testy, a Ty go frywolnie zakomitowałeś bez wcześniejszego przeczytania? Z pewnością nie raz. Każdy tak zrobił. To tyczy się tego samego co powyższy punkt. Nie chcesz zostawiać kodu do następnego dnia? Przynajmniej go przeczytaj przed wrzuceniem. Gwarantuję, że znajdziesz coś do poprawy.
7. Brak testów
Sprawa tak oczywista, że część osób powie mi, że bredzę. A zresztą, co mają testy do jakości kodu? Bardzo wiele, ale przytoczę dwie najważniejsze właściwości. Po pierwsze posiadając dobre testy nie będziesz się bał refaktoringu, przez co kod będzie lepszy. Natomiast chcąc napisać dobry test to kod aplikacji musi być testowalny, a gdy jest testowalny to jest bardzo prawdopodobne, że jest czysty i pachnący.
8. Uzależnienie od frameworku
Bardzo często spotykany problem. Ludzie nie grupują kodu według domen biznesowych, lecz bazują na strukturze dostarczanej przez framework. W takiej konfiguracji bardzo ciężko jest odnaleźć logicznie powiązane elementy. W jaki sposób zrobić to inaczej? Polecam zapoznać się z Onion Architecture oraz z książką “Czysta Architektrura”, którą opisywałem.
Podsumowanie
Ile zauważyłeś punktów w swoim projekcie? Jeżeli 2-3 to kod w Twoim projekcie jest raczej czysty i przyjemny, choć jeszcze jest pole do poprawy. Jest tego więcej? Zatrzymaj się na chwilę i przeanalizuj czy na pewno idziecie w dobrą drogę, bo od pewnego miejsca nie ma już powrotu.
Czy zgadasz się z tymi punktami? A może uważasz, że warto by dorzucić coś jeszcze? A może chcesz, bym któryś temat rozwinął? Daj znać w komentarzach.
5 Komentarzy
Patryk · 2019-01-25 o 13:02
Wszystko to, sprowadza się do świadomości i doświadczenia zespołu, a także przyjętych w teamie standardów. Owszem, niektóre elementy można wprowadzać i stosować samodzielnie, ale jednak nasza praca jest grą drużynową. To jest taki temat, moim zdaniem, który powinien być wszędzie, ciągle i wciąż wałkowany. Tak aby wszyscy myśleli w tych kategoriach. Oczywiście wszystko z rozsądkiem.
Jerzy Wickowski · 2019-01-25 o 13:41
Cześć @Patryk,
Dzięki za komentarz. Pewnie, że tak. Pracując w zespole, jest to nawet ważniejsze, by poszczególni członkowie byli w stanie bez problemu czytać kod.
Michał Kuliński · 2019-02-01 o 11:10
Świetny artykuł. Znam jeszcze lepszy sposób niż punkt 5. :
Poprogramuj w parze z kolegą. To nazywa się Pair Programming. Rośnie Wasza wspólna wiedza, wzrasta jakość kodu. Wraz z kolejną parą oczu liczba bugów maleje. Gdy robicie to jeszcze w TDD to już jest mistrzostwo świata. No i nie ma obrazy majestatu, jak to się często zdarza po Code Review. Tutaj od razu moeżcie dać sobie w mordę (wyjaśnić nieścisłości ;-) ) i dbać o dostarczanie wartości do klienta, a nie o osobiste animozje.
Jerzy Wickowski · 2019-02-07 o 10:09
Cześć @Michał.
Dziękuję ślicznie za miłe słowa.
Odnośnie programowania w parach to uważam, że jest to naprawdę dobry sposób na świetny kod. Jednak muszą zostać spełnione specyficzne warunki, by miało to zastosowanie. Po pierwsze powinien to być nietrywialny problem algorytmiczny, by ta para miała o czym dyskutować. Po drugie te osoby też powinny umieć pytać, tłumaczyć i słuchać, by taka współpraca była owocna.
Robert Krzaczyński · 2020-03-02 o 21:57
Nie sposób się nie zgodzić z tymi punktami. ;) Mam nadzieję, że nadejdzie moment, kiedy w refaktoring będzie praktyką stosowaną w każdym teamie, bo na ten moment bywa z tym chyba jeszcze różnie.