Mantra architektoniczna

Skąd nowe osoby w Waszym zespole zdobywają wiedzę na temat działania systemu? Z nieaktualnej dokumentacji, czy raczej bardziej doświadczony programista poświęca swój czas na przybliżenie wszystkich elementów systemu? Jak często widzicie kod, który znalazł się w nieodpowiednim miejscu aplikacji?

Akt I

Czytając kod czasami ma się wrażenie, że ktoś pisał go w pośpiechu, bez żadnego przemyślenia. Dlaczego logika biznesowa znajduje się w DAO? Dlaczego zwykły obiekt DTO ma w środku w getterze jakiś rozbudowany algorytm? Dlaczego ta klasa ma 10 tysięcy linii? Za co ta klasa tak w ogóle odpowiada?! Takich bólów w programistycznych kościach można wymieniać bez końca. Jakie jest panaceum? Rzucić wszystko i wyjechać w Bieszczady.

A tak na poważnie, jak rozpropagować w całym zespole wiedzę tajemną o tym, jak wygląda architektura systemu, do której dążymy? W końcu architektura nie jest czymś, co architekt przygotowuje w białej wieży i zrzuca zwykłym programistom jako gotowy dizajn. Architektura jest czymś, co ciągle ulega zmianie razem z wymaganiami klienta; czymś, co ciągle możemy ulepszać, zmieniać tak, żeby zarówno programista był zadowolony z tego, że pracuje w projekcie, jak również i PM, któremu będzie zgadzać się kasa.

W końcu dobra architektura i czysty kod powinny zapewnić możliwość szybkiego wprowadzania zmian w systemie, za które klient zapłaci. Żeby ta architektura zmieniała się na lepsze i w jednym kierunku (a nie w tylu kierunkach, ilu jest developerów w zespole), każdy musi wiedzieć, za co odpowiada nawet najmniejszy element tej układanki. Można to osiągnąć poprzez ciągłe powtarzanie tych informacji, aż każdy - nawet stażysta - załapie jak to działa.

Ale o co chodzi?

Takim ciągłym powtarzaniem informacji o systemie, definiowaniem na nowo każdej warstwy i cegiełki naszego systemu jest właśnie mantra architektoniczna. Co tak w ogóle oznacza słowo „mantra”? Definicja z wiki mówi ot, tyle:

Mantra – w buddyzmie, hinduizmie i ezoteryce formuła, werset lub sylaba, która jest elementem praktyki duchowej. Jej powtarzanie ma pomóc w opanowaniu umysłu, zaktywizowaniu określonej energii, uspokojeniu, oczyszczeniu go ze splamień. Szczególnie istotną sprawą jest bezpośredni przekaz z ust wykwalifikowanego nauczyciela (guru), gdyż tylko wtedy mantra uzyskuje właściwą moc.

Definicja porusza dwie bardzo ważne kwestie, które mają również odniesienie do mantry architektonicznej. Pierwsza rzecz to to, że mantra składa się z tylko jednego wersetu lub sylaby - a co za tym idzie - jest bardzo krótka. Taka również powinna być mantra architektoniczna. W moim zespole mantra zazwyczaj trwa jedynie 20 minut. Myślę, że jest to czas, jaki każdy PM może zaakceptować jako sposób na utrzymanie systemu w lepszej formie.

Druga kwestia to powtarzanie mantry. Zrobienie jednorazowego spotkania nic nie da, ponieważ niedoskonały człowiek bardzo upodobał sobie zapominanie różnych rzeczy. Żeby mantra miała sens, musi być powtarzana regularnie przez dłuższy czas, co początkowo może zdawać się zbyt monotonne - jednak regularność bardzo szybko się opłaci. Z doświadczenia wiem, że spotkanie raz w tygodniu absolutnie wystarczy, jednak nie powinno dojść do sytuacji, kiedy w danym tygodniu nie ma mantry, bo mamy akurat pożar na produkcji albo klient domaga się kilku nowych funkcjonalności na wczoraj.

Najlepiej, żeby mantra miała stałą godzinę, o której zespół spotyka się bez względu na aktualną sytuację w projekcie. W podjęciu decyzji o spotkaniu mimo trudnej sytuacji pomoże na pewno wspomniany fakt, że mantra trwa krótko. Można ją traktować jako przerwę od ciągłego patrzenia w monitor. Będzie to kilka minut, kiedy programista zobaczy innego programistę siedzącego obok, być może nawet odezwie się do niego i na chwilę oderwie od zadania, jakie realizuje od kilku godzin.

Jak to robić?

Mantra ma być jak napad na bank - szybka i konkretna. Siadamy w kółku na czym się tylko da - krzesłach, podłodze - i zaczynamy nakreślać, z jakich warstw składa się system. Możecie zacząć od samego dołu lub od samej góry - nie ma to znaczenia. My zaczynamy od warstwy widoku – tego, co widzi klient w swojej przeglądarce. W końcu robię aplikacje webowe i czasami coś w tej przeglądarce - oszpeconego CSS-em - uda się zaprezentować.

Po omówieniu widoku idziemy dalej - usługi, serwisy, baza danych - każdy kolejny element systemu. Przy omawianiu danej warstwy wypisujemy na whiteboardzie, za co dana warstwa odpowiada, co powinno się tu robić, w jaki sposób, z czego korzystać oraz to, czego nie powinno tutaj być. Przy omawianiu ciemnych stron danej warstwy zdarzy się, że któryś z programistów obleje się rumieńcem - taki rodzaj blame w realu.

Oprócz omówienia tego, jak jest i jak powinno być, na spotkaniu ustalamy również kierunek działania. Umawiamy się czego pozbyć się z danej warstwy, co zrefaktorować, jaka konwencja panuje w danej warstwie. Bardzo ważne jest, żeby na spotkaniu angażować wszystkich członków zespołu - nie może być prowadzone tylko przez jedną osobę. Każdy powinien wypowiadać się o systemie tak, żeby można było ewentualnie prostować jego światopogląd (jeżeli istnieje zagrożenie, że może nam zrobić bałagan w systemie).

Bardzo przydatna podczas spotkania jest tablica, na której wszystko wizualizujemy. Prawie nigdy jej nie ścieramy - ciągle coś zmieniamy, dopisujemy, ale bardzo rzadko usuwamy coś, co już zostało napisane. Tablica jest w pokoju, gdzie siedzi cały zespół i często widuje się programistów zajadających kanapki, spacerujących w zamyśleniu obok niej. Sprawiają wtedy wrażenie jakby studiowali, co na niej się znajduje. Na takiej tablicy czasami wiszą również wydrukowane fragmenty kodu, przedstawiające wzorcowe implementacje oszczególnych klocków aplikacji.

Podsumowanie

Mantra jest krótkim spotkaniem przeprowadzanym w zespole w celu omówienia budowy systemu, strategii dostosowania architektury do zmieniających się wymagań klienta. Uczestnictwo w takich spotkaniach jest również jedną z najkrótszych sposobów na wdrożenie nowego członka zespołu. Zanim narobi bałaganu w systemie zdąży się dowiedzieć, co gdzie powinno się znajdować.

W sytuacji, kiedy nie mamy spisanej dokumentacji do systemu, mantra stanowi jakiś nośnik wiedzy. Wypisane informacje na tablicy można sfotografować - i to już jest jakaś forma dokumentacji. Jeżeli mamy nieaktualną to taka będzie dużo lepiej opowiadać o systemie i będzie zawsze aktualna.

Jeżeli nie robiłeś tego nigdy w swoim zespole - spróbuj. Zwołaj zebranie i zapytaj każdego o odpowiedzialności poszczególnych elementów systemu. Zdziwisz się, jak wiele różnych odpowiedzi dostaniesz i jak bardzo różną wizję mogą mieć programiści. Podczas takiego spotkania pojawiają się również pytania, na które odpowiedź powinien znać każdy, a niekoniecznie tak jest.