Nie czytałam do teraz książek związanych z IT, zwłaszcza tych związanych z jakąś konkretną technologią. Takie treści wolę pochłaniać w formie wideo, ewentualnie jako artykuły w internecie. Książki w takich tematach potrafią się ekspresowo starzeć. Ale nie to jest największym problemem książki, o której powiem, a jest nią chyba wszystkim znany przynajmniej ze słyszenia, “Czysty kod” Roberta C. Martina (link afiliacyjny).

Autor pracował w IT w czasach, kiedy na chleb mówiłam “bep” i myślałam, że zabawa w chowanego polega na zamknięciu oczu (wiadomo, jak ja nikogo nie widzę, to nikt nie widzi mnie). Sprawdziłam i to ten człowiek zaproponował powszechnie znane zasady SOLID. Czy warto więc zabrać się za tę książkę? Jeden rabin powie tak, a inny powie nie. Ja po przeczytaniu części tej książki raczej jej nie polecam, na pewno nie każdemu. Nie znaczy to jednak, że ta książka jest nic nie warta i że zupełnie nic z niej nie wyciągniesz. Polecam doczytać do końca dla pełnego obrazu.

“Ej, ale moment, jak to części książki? Znaczy odradzasz książkę, której nie przeczytałaś w całości?”

Dokładnie tak. Gdybym ją dała radę zmęczyć w całości, to pewnie bym jej też nie odradzała (ale to zależy). Jakoś od połowy książki dzieją się rzeczy niesłychane. A te rzeczy to ściany kodu w drukowanej książce. Zakładam, ża autor chciał pokazać pogłębione przykłady tego, o czym mówił w pierwszej połowie książki, ale moim zdaniem książka nie jest formatem na takie rzeczy. Mówcie co chcecie, ale czytanie kodu bez kolorowania składni to tortury dla oczu, mózgu i duszy i nawet dla dobra recenzji nie dałam rady tego przemęczyć.

W pierwszej połowie natomiast jest treść, którą da się czytać. A nawet warto! Tam znajdują się rozdziały, którymi się inspirowałam, gdy tworzyłam treści do newslettera. Znajdziecie tam na przykład dużo informacji o tym jak nazywać metody, jakich słów unikać w nazwach klas, ile argumentów powinna mieć metoda albo czym jest zasada FIRST w testowaniu. O samym testowaniu w tej książce niewiele znajdziemy. Zresztą sam autor przyznaje, że mogłaby powstać cała książka o nazwie “Czyste testy”. 

W książce znajdziemy także kilka ważnych spostrzeżeń, które rezonują ze mną wyjątkowo mocno. Jednym z nich jest obserwacja autora, że częściej czytamy kod niż go piszemy i właśnie dlatego musi być czytelny i zrozumiały. Autor dzieli się również poglądem, że kod testów powinien być równie “czysty” co kod produkcyjny. Więcej takich spostrzeżeń znajdziesz także tutaj.

Problemem nie jest natomiast co autor pisze, ale jak. Wszystko wydaje się brzmieć jak zbiór zasad nie do ruszenia. Jeżeli założyć, że ja jestem z planety “To zależy”, to autor jest z planety “Sztywniutko”, gdzie wszystko jest jasne i na sztywno. Parafrazując autora, najlepsze metody to takie bez argumentów, a trzy argumenty to już chaos i lepiej ograniczyć ich liczbę. Może się nie znam, ale uważam, że jeżeli mamy na siłę redukować liczbę argumentów metody, to z czegoś co miało sens biznesowy albo logiczny, często wyjdzie potworek. Jeżeli chodzi o zawartość merytoryczną, to ktoś już “zrezencował” tę książkę tutaj.

Do większości zasad, które autor podaje można dodać rozwinięcie “tak, jeżeli to ma sens”. Gdyby autor pokazał przykłady, gdzie dana zasada rzeczywiście ma sens, a gdzie niekoniecznie warto się jej trzymać na siłę, to ta książka miałaby szansę być naprawdę fajną książką dla osób stawiających pierwsze kroki w programowaniu.

Nie zliczę sytuacji, w których w ramach testelka.pl otrzymałam pytanie od jakiegoś studenta w stylu: “Ale to jak ma w końcu być, tak czy tak?”. Tak łatwo to nie ma. No chyba, że w “Czystym kodzie”. Nie polecam tej książki każdemu właśnie dlatego, że trzeba w trakcie czytania założyć okulary z filtrem “to zależy”, a tego osoby początkujące, do których mam wrażenie skierowana jest książka, jeszcze nie potrafią, a często nawet nie chcą zrobić.