Książki są jednym z moich ulubionych sposobów na pozyskiwanie nowej wiedzy. Na moim blogu możesz znaleźć listę książek, które uważam za godne polecenia. Nie było jednak wcześniej okazji do napisania pełnoprawnej recenzji książki. Ostatnio w moje ręce wpadła pozycja A Philosophy of Software Design, której autorem jest John Ousterhout. Myślę, że jest to dobra pozycja do przetarcia szlaków dla dalszych recenzji na moim blogu.

Wszystkie stwierdzenia i opinie zawarte w tej recenzji są moją subiektywną opinią i rozumiem, że możesz się z nimi nie zgodzić. Chętnie poznam inne opinie i wejdę w polemikę, stąd zachęcam do dyskusji w sekcji komentarzy. Ponieważ jest to pierwsza recenzja na blogu, będę też ogromnie wdzięczny za uwagi i sugestie co można zrobić lepiej.

A Philosophy of Software Design

Na samym początku warto nakreślić ogólny zakres tematyczny A Philosophy of Software Design. Książka, w mojej opinii dzieli się na dwa oddzielne bloki tematyczne.

Pierwszy z bloków poświęcono problemowi złożoności oprogramowania. Autor rozpoczyna książkę opisaniem, jak definiuje złożoność. Podkreśla, że rosnąca złożoność systemu jest procesem długotrwałym i składa się na nią wiele przyczyn oraz ma wiele objawów. Przedstawia konkretne problemy, jakie mogą wystąpić w kodzie powodujące wzrost złożoności. Nie zabrakło również opisu konsekwencji wynikający z wysokiej złożoności. Jak w wielu innych zbliżonych tematycznie pozycjach, autor opisał dwa najczęściej omawiane podejścia do procesu wytwarzania oprogramowania — waterfall i agile. W przeciwieństwie do innych książek temat ten został przedstawiony zwięźle i treściwie co jest dużym plusem recenzowanej książki.

Moją szczególną uwagę zwrócił rozdział Working Code Isn’t Enough, w którym opisane zostały dwa podejścia do wytwarzania oprogramowania — taktyczne i strategiczne. Czyniąc długą historię krótką, programowanie taktyczne zostało zdefiniowane jako szybkie rozwiązywanie problemów kosztem jakości zaprojektowanego rozwiązania. Opisując podejście taktyczne, autor przedstawił także zjawisko tactical tornado, czyli programisty cechującego się niewiarygodnie szybkim tempem dostarczania rozwiązania, pracującego całkowicie w podejściu taktycznym. Czytając ten opis, miałem refleksję, że sam czasami pasuję do tego opisu, z czego nie do końca jestem zadowolony. Takich refleksyjnych momentów w całej książce miałem kilka. W opozycji do programowania taktycznego przedstawione zostało podejście strategiczne. Promowane tutaj jest podejście uwzględniające jakość dostarczanego oprogramowania i bierze pod uwagę jego długoterminowy rozwój i utrzymanie. Jest to podejście preferowane i rekomendowane przez autora, o czym świadczy choćby nazwa jednego z rozdziałów — Design it Twice.

W kilku kolejnych rozdziałach John Ousterhout przedstawia sposoby na uproszczenie architektury oprogramowania. Autor skupia się na modularyzacji kodu, separacji warstw oraz prawidłowego określenia abstrakcji w kodzie. Rozdziały poświęcone modularyzacji traktują o tym, jak powinien wyglądać interfejs modułu oraz jak dzielić odpowiedzialności na moduły. W tej części doświadczyłem drugiej refleksji. Moją uwagę przykuło zjawisko pass-through methods. Jest to zjawisko, gdzie kolejne warstwy abstrakcji nie przynoszą żadnej wartości dodanej, a jedynym zadaniem takich metod jest wywołanie innej metody. Z pewnością znalazłbym kilka takich metod w swoim kodzie. Ostatnim zagadnieniem opisanym przez autora związanym ze złożonością oprogramowania jest prawidłowy error handling. Autor pokazuje, jak niepoprawna obsługa błędów może prowadzić do wzrostu złożoności systemu.

Co oprócz złożoności?

W drugiej części książki poruszone zostały inne, niemniej ważne, zagadnienia powiązane z designem i wytwarzaniem oprogramowania. W tej części książki duża uwaga została poświęcona komentarzom w kodzie. Autor zdecydowanie nie jest zwolennikiem podejścia, że dobry kod komentuje się sam (osobiście uważam to stwierdzenie za szkodliwe). Wręcz przeciwnie, autor przedstawia wytyczne jak pisać dobre komentarze, co powinny zawierać oraz kiedy należy je pisać. Oprócz omawianej książki więcej o tym zagadnieniu możesz się dowiedzieć z mojego artykułu Komentarze w kodzie.

Niemniej jednak uważam, że w rozdziale opisującym comment-first approach autor nieco „popłynął”.  Sam często rozpisuję w komentarzu listę kroków, jakie mój kod ma wykonać w formie pseudokodu. Jednakże, po napisaniu implementacji usuwam uprzednio przygotowany pseudokod. Dokumentowanie kodu przed jego napisaniem uważam za przerost formy nad treścią oraz bardziej problem niż potencjalną korzyść. Kod jest żywym tworem, co wręcz bije z treści recenzowanej książki. Kod jest często zmieniany, przez co dokumentacja również musi być modyfikowana. Wielokrotnie potrafiłem napisać kod, żeby chwilę później usunąć go i zacząć implementować go od nowa lub sprawdzać inne podejście.

Oprócz komentarzy autor zwraca też uwagę na czytelność i spójność kodu. Osobny rozdział został poświęcony zagadnieniu odpowiedniego nazewnictwa w kodzie. To często pozwala zaoszczędzić kilku wspomnianych już komentarzy.

Zawsze musi być jakieś ale

O ile zdecydowana większość książki wnosi sporo cennej wiedzy, tak rozdział Software Trends, jest według mnie dodany na siłę. Autor porusza w nim wiele klasycznych zagadnień związanych z rozwojem oprogramowania takie jak testy jednostkowe, TDD, wzorce projektowe czy paradygmat programowania obiektowego. Niemniej jednak wszystkie te tematy są potraktowane bardzo powierzchownie i omawiany rozdział jakością odstaje od reszty książki. Sam rozdział również nie wnosi za wiele względem reszty książki. Książka nie straciłaby nic, gdyby ten rozdział został wycięty. Może on mieć wartość dodaną dla programistów na bardzo wczesnym etapie rozwoju, jednak myślę, że nie są oni grupą docelową reszty książki. Taki programista prawdopodobnie nie miał styczności z oprogramowaniem o dużej złożoności, więc mam wątpliwości czy doceni, jak wiele wartości ta pozycja wnosi.

Drugim mankamentem książki są rysunki, które często nie wnoszą nic ponad to, co jest zawarte w tekście. Tutaj, podobnie tak jak w przypadku rozdziału Software Trends, brak rysunków nie sprawiłby, że książka straciłaby na jakości.

Dodatkowe aspekty

Książka z pewnością jest wartościowa, natomiast nie uważam jej za innowację. Większość praktyk czy opisanych wzorców już gdzieś zostało przedstawione. Nie jest to oczywiście wada, lecz myślę, że warto poruszyć ten aspekt. Istotny odsetek książek czy treści dostępnych w Internecie bazuje na twórczości innych. Doskonałą lekturą uzupełniającą jest Refactoring autorstwa Martina Fowlera. Sam autor na samym początku informuje, że nie jest to ostatnie słowo w filozofii wytwarzania oprogramowania, lecz wnioski z jego wieloletniego doświadczenia. Widać to po podobnych wnioskach, do jakich dochodzi Fowler. Najwidoczniej inteligentni ludzie często dochodzą do podobnych wniosków.

Sama książka napisana jest prostym językiem. Użyty angielski nie powinien stanowić problemu, słownictwo jest proste i zrozumiałe. Zdecydowanym plusem jest także sama długość pozycji. Autor nie leje wody, dzięki czemu książkę czyta się szybko i jest możliwe przeczytanie je przy 1 dłuższym posiedzeniu. Rekomendowałbym jednak przeczytanie jej w co najmniej dwóch sesjach. O ile rysunki uważam za niezbyt wartościowe, tak kody (Java/C++) są krótkie, zrozumiałe i jednoznaczne i przede wszystkim przydatne. Szczególnie wartościowe są sekcje z czerwonymi flagami, gdzie autor w pigułce streszcza kluczowe informacje opisane w książce.

Podsumowanie

Mój werdykt co do tej pozycji jest jednoznaczny — zdecydowanie warto przeczytać tę książkę. Myślę, że jest to bardzo dobra pozycja dla programistów, którzy mieli już styczność z jakimś projektem komercyjnym. Głównie ze względu na fakt, że będą świadomi istotności opisanych problemów. Programistom wannabe rekomenduję zapisanie sobie tej pozycji na liście „na później” i powrót do niej po rozpoczęciu pierwszej pracy, gdyż dopiero wtedy docenicie tę książkę.

A Philosophy of Software Design można zakupić zarówno w formie papierowej, jak i e-booka na Kindle’a na Amazonie (link nie jest reklamą ani linkiem referencyjnym).

Na sam koniec zachęcam do objerzenia wykładu John Ousterhouta o takim samym tytule jak recenzowana książka. Zapraszam także do zapoznania się z materiałami dodatkowymi.

Materiały dodatkowe

• A Philosophy of Software Design: Book Review and Verdict – Video
• A Philosophy of Software Design | John Ousterhout | Talks at Google
• A Philosophy of Software Design: My Take (and a Book Review)
• The hidden cost of complexity

Zaobserwuj mnie na LinkedIn!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zaobserwuj mój profil na LinkedIn, by być na bieżąco!
Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

Chcesz docenić moją pracę? Postaw mi kawę!