Skąd nowe osoby w Waszym zespole zdobywają wiedzę na temat działania systemu? Z nieaktualnej dokumentacji? Czy bardziej doświadczony programista poświęca swój czas na przybliżenie wszystkich elementów systemu? Jak często widzisz kod, który znalazł się w nieodpowiednim miejscu Twojej aplikacji?
UWAGA. Tekst z nutą kpiny, zakrapiany moim poczuciem humoru. Wrażliwych programistów uprasza się o nieczytanie tego porywającego wpisu.
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 sie 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 na te bóle? 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, coś, co ciągle możemy ulepszać, zmieniać tak, żeby zarówno programista był zadowolony z tego, że pracuje w projekcie, jak i również PM, któremu będzie zgadzać się kasa. W końcu dobra architektura i czysty kod powinny zapewnić możliwość wprowadzania szybko 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ągle 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 ta mówi o dwóch bardzo ważnych kwestiach, które również mają 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. 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. Lepiej ż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 fakt, że mantra jest krótkim spotkaniem. Może byc zrobiona jako przerwa 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 nie zważając na pełny pęcherz i brak batoników do zjedzenia.
Jak to robić?
Mantra ma być jak napad na bank, szybka i konkretna. Siadamy w kółku na czym sie tylko da - krzesła, podłoga, pośladki - 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, od tego klient widzi w swojej przeglądarce. W końcu robię aplikacje webowe,
czasami coś w tej przeglądarce, oszpecone 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 tego, jakie są ciemne strony 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 takich spotkaniach angażować wszystkich członków zespołu, może tego prowadzić tylko jednak osoba. Każdy powinien się wypowiadać o systemie, tak żeby można było ewentualnie prostować jego światopogląd jeżeli może nam to 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 kanapkę i spacerujących w zamyśleniu obok tablicy. 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 poszczegó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 takim spotkaniach jest również jedną z najkrótszych sposobów na wdrożenie nowego członka zespołu. Zanim narobi bałaganu w systemie już będzie wiedział gdzie, co powinno się znajdować. Nie mając 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 zawsze będzie aktualna. Jeżeli nie próbowałeś nigdy tego 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, 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.