Czysty kod – recenzja książki

Cześć,

dzisiejszy post chciałabym poświęcić tematyce czystego kodu omawiając znaną książkę „Czysty kod” Roberta Martina (czyli słynnego wujka Boba).

W świecie programistów (zwłaszcza Javy) książka „Czysty kod” stała się swoistą biblią. Można się zgadzać, można się kłócić, ale wypada przeczytać albo chociaż wiedzieć jakie jest jej przesłanie.

Niestety w świecie testerów automatycznych nie spotkałam się z tematyką czystego kodu i ogólnie dbania o jakość kodu zgodnie ze standardami programistycznymi. Kluczową kwestią jest, aby kod działał. Natomiast o to jak wygląda i czy jest czytelny troszczą się nieliczni (oczywiście jest to moja subiektywna opinia).

Myślę, że z czasem będzie się to zmieniać (przynajmniej taką mam nadzieję), gdyż kod testów również musi być utrzymywany. Co za tym idzie znacznie więcej razy jest czytany niż pisany i dobrze jakby utrzymywanie go nie było drogą przez mękę.

Wracając jednak do samej książki „Czysty kod” (ang. clean code), autor omawia w niej zagadnienia takie jak:

  • Nadawanie „mówiących” nazw

Przykładowo zamiast zmiennej:

int d;

piszemy :

int elapsedTimeInDays;
  • Unikanie dezinformacji w kodzie

Tutaj chodzi głównie o unikanie mylących nazw (np. stosowanie skrótów, które zazwyczaj mają już ustalone znaczenie inne od naszego).

  • Używanie nazw, które później łatwo wyszukać

Chodzi o to, że nazwy będące pojedynczymi literami lub cyframi później pojawiają się w wielu miejscach w kodzie.

  • Podział kodu na funkcje

Funkcje powinny być niewielkie i zajmować się jedną rzeczą. Nazwa funkcji powinna opisywać jej działanie.

  • Zasada DRY – Don’t repeat yourself

To w sumie mówi samo za siebie –  im mniej redundancji w kodzie tym łatwiej później taki kod utrzymać.

  • Komentarze

Wiele osób nagminnie używa komentarzy w kodzie.  Niestety nie jest to dobra praktyka.

Przede wszystkim komentarze zaśmiecają kod. Kod powinien być tak napisany, aby dało się go zrozumieć bez komentarzy. Jeśli kod wymaga komentarza, aby wyjaśnić co on robi to znaczy, że został źle napisany i należy go poprawić. Ponadto komentarze są rzadko aktualizowane i szybko zaczynają wprowadzać w błąd.

Właściwie komentarz może być uzasadniony jedynie wtedy, gdy wyjaśnia dlaczego zastosowaliśmy jakieś rozwiązanie (np. jakaś specyfika projektu). Czasami są konieczne komentarze z prawami autorskimi, ewentualnie komentarze Javadoc.

  • Formatowanie kodu

Kod powinien być sformatowany (tą funkcję zapewnia IDE). Ważne, żeby cały zespół, który tworzy dany kod, formatował go według tych samych reguł.

 

Autor omawia też kilka bardziej zaawansowanych zagadnień jak:

  • Prawo Demeter (Law of the Demeter)

Prawo mówiące, że moduł nie powinien znać szczegółów wewnętrznych obiektu, którego używa/zmienia.

Precyzyjniej mówiąc prawo Demeter mówi, że metoda f klasy C powinna uruchamiać tylko metody, które należą do: klasy C,  obiektów stworzonych w metodzie f, obiektów przekazanych jako argument do metody f, obiektów instancyjnych klasy C.

  • Obsługa błędów

Tutaj autor przekazuje nam sporo informacji. Kilka kluczowych to używanie wyjątków niesprawdzalnych (unchecked exceptions), nie zwracanie wartości null w przypadku wystąpienia błędu.

  • Testy jednostkowe (w tym dość obszerne omówienie JUnit).

oraz wiele innych zagadnień.

 

Ogólnie moim zdaniem książka jest ciekawa, dobrze się czyta, mogłaby być trochę bardziej skondensowana, ale mimo tego bardzo polecam. Na pewno będę do niej wracać.

Moja ocena:4.5/5.

 

Do kolejnego posta!

 

PS. Jeśli nie macie czasu albo ochoty zapoznawać się z tą lekturą (choć polecam) to proponuję odszukanie prezentacji wujka Boba na temat czystego kodu na YouTube i choćby skrótowe poszerzenie wiedzy na ten temat.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *