Wprowadzenie

Tym razem dwie książki formalnie adresowana przez autora dla programistów (autor książki jest znany w sieci jako Uncle Bob) . Długo się nad nimi zastanawiałem ale w końcu kupiłem i nie żałuję mimo, że UML napisana w 2003, czysto kod to „nówka” z 2018 roku.

Po pierwsze jako projektant muszę (no powinienem ;)) znać język koderów/programistów. Po drugie jako analityk, nie raz sprawujący nadzór autorski nad developerem, muszę (no powinienem ;)) mieć z tymi ludźmi wspólny język.

Dlatego są to książki także dla „analityków biznesowych” bo adresatami ich dokumentów są właśnie deweloperzy chcący (a nie raz po prostu muszą) z nich skorzystać!

Agile jest definiowane jako odnosząca się do, lub oznaczająca metoda zarządzania projektami, stosowana zwłaszcza do tworzenia oprogramowania, która charakteryzuje się podziałem zadań na krótkie etapy pracy oraz częstą ponowną oceną i dostosowywaniem planów. Powszechnie uważa się, metody zwinne zastępują projektowanie na wysokim poziomie częstym przeprojektowywaniem (źr.: Dictionary Definitions from Oxford Languages).

Robert C. Martin to jeden z sygnatariuszy Agile Manifesto, który bardzo szybko zorientował się, że wraz z kolegami, obudzili hydrę i już po dwóch latach od ogłoszenia Manifestu, zaczęli publikować książki o projektowaniu poprzedzającym kodowanie. Czysty kod to wydana w 2018 roku książka, w której autor jeszcze dobitniej wskazuje na potrzebę tworzenia architektury HLD przed kodowaniem i na stosowanie standardu komunikacji i dokumentacji jakim jest notacja UML. Tworzenie modeli UML dopiero po powstaniu kodu to najbardziej pozbawiona sensu praca. Martin przytacza znane już w 2018 roku dane z rynku o efektach agile (15 lat agile na rynku): drastyczne pogorszenie jakości i wzrost kosztów.

UML for Java programmers

Książka doskonale pokazuje to co zawsze mówię na szkoleniach: UML jako notacja jest nadmiarowa i nie wolno o tym zapominać (czasem mam wrażenie, że autorzy wielu diagramów, jako zadanie, postawili sobie użycie za wszelka cenę wszystkich symboli UML jakie zobaczyli).

Przypadki użycia

Jednym z najbardziej (po diagramie klas) nadużywanym jest diagram przypadków użycia. Na każdym szkoleniu zawsze mówię: to ma być prosty diagram, wszelkie extends, include, dziedziczenie to dzisiaj bełkot UML-owy (te związki powstały w latach 80-tych, gdy diagram UC był samodzielnym tworem, nie znającym diagramów klas czy komponentów… ).

Po drugie kolejna ważna rzecz: w toku procesu tworzenia oprogramowania powstają modele pojęciowe (tak conceptual znaczy pojęciowy a nie konceptualny czy koncepcyjny!) oraz modele logiki i architektury. Autor książki opisuje dwa ostatnie, w końcu to książka dla programistów, ale nie zakazana dla analityków. Od siebie dodam, że w ramach analiz wymagań powstają modele pojęciowe i (nie raz uproszczone) architektura + logika (algorytmy, scenariusze).

O modelowaniu

Po co modelować?

Clean architecture

To pozycja w 100% dla architektów-projektantów realizacji wymagań funkcjonalnych aplikacji. Ta książka jest także dostępna w wersji polskiej . Generalnie jest jeden z najlepszych, ilustrowanych modelami UML, podręczników projektowania architektury aplikacji.

We wstępie autor pisze:

Świat fizyczny jest miejscem, w którym żyjemy my, nasze firmy i nasze gospodarki. Daje nam to kolejną kalibrację, dzięki której możemy zrozumieć architekturę oprogramowania, inne mniej fizyczne siły i wielkości, za pomocą których możemy rozmawiać i rozumować. „Architektura reprezentuje istotne decyzje projektowe, które kształtują system, gdzie istotność jest mierzona kosztem zmiany.” -Grady Booch.
Czas, pieniądze i wysiłek dają nam poczucie skali, aby odróżnić rzeczy duże od małych, aby odróżnić rzeczy architektoniczne od reszty. Ta miara mówi nam również, w jaki sposób możemy określić, czy architektura jest dobra, czy nie: Dobra architektura nie tylko spełnia potrzeby użytkowników, programistów i właścicieli w danym momencie, ale także spełnia je w czasie.
„Jeśli uważasz, że dobra architektura jest droga, wypróbuj złą architekturę.” -Brian Foote i Joseph Yoder

W pierwszym rozdziale Martin przytacza znane w czasie pisania książki efekty agile (kodowanie z pominięciem planowania i budowania architektury HLD): drastyczne pogorszenie jakości i wzrost kosztów utrzymania i rozwoju: owszem MVP powstaje szybko i efektywnie, ale potem jest już tylko coraz gorzej:

Produktywność w kolejnych wersjach:

Koszty developmentu w kolejnych wersjach:

W całej książce Martin, do ilustrowania jej treści, używa czasami pseudokodu ale przede wszystkim diagramów UML (głównie diagramy komponentów, czasami diagramy klas i przypadków użycia).

Książka zawiera w zasadzie pełne kompendium zagadnień związanych z architekturą: paradygmaty, kluczowe wzorce projektowe i najlepsze praktyki oraz wiele, wiele przykładów.

Nie jest moją ambicją streszczanie tu tej książki, to pozycja z gatunku „must have”. Polecam ją nie tylko z powodu jej treści, ale także z powodu daty napisania: 2018. Jest to – jak na warunki cyklu wydawniczego takich książek – świeża pozycja, na dodatek bardzo wartościowa patrząc na doświadczenie i dorobek R.C. Martina.

Na zakończenie

Gorąco polecam programistom, by w ogóle zaczęli korzystać z UML a analitykom, by wyleczyli się z wielu mitów o UML rozpowszechnianych niestety na wielu, nie zawsze tanich, szkoleniach i w wielu kiepskich „poradnikach UML” (pisanych nie raz nawet przez uczelnianych doktorów i nie tylko)….. Może wtedy przestaną tworzyć nieprzydatne dokumentacje. 

Poniżej także – o dziwo jest dostępna – wersja pdf do pobrania.

UML for Java Programmers, June 6, 2003 by Robert C. Martin (Author): papierowe wydanie na Amazonie i do pobrania pdf (pobieżne przejrzenie wersji pdf wskazuje że jest troszkę uboższa).

Polecam także blog R. C. Martina: https://blog.cleancoder.com/

Źródła