Samozagładę projektów powstrzymuje architektura, nie twój sprytny kod. Zapomnij o zakurzonych księgach, które juniorzy omijają w księgarniach szerokim łukiem. Wyobraź sobie czterech typów od backendu. Każdy z nich inaczej klepie format błędu HTTP 400, bo „tak mu się wydaje lepiej”. Szału dostajesz w piątek o 16:47. Slack wyje bez litości. Odkrył właśnie frontendowiec, że errorCode raz przychodzi jako elegancki string, a raz jako surowa liczba od czapy. Zżerają sprinty bez popitki takie cyrki. Jire w wysypisko śmieci zamieniają, do którego nikt bez maski gazowej i litra melisy zaglądać nie chce.
Komunikacyjny syf w czystej postaci nas zabija, nie problem techniczny. Wspólny język, umowę, wręcz krwawy cyrograf – tak traktuj architekturę. W nagłówku ustalamy licznik, w URL-ach rzeczowniki i jałowej dyskusji koniec. Robisz to, żeby przy każdym commicie nowa osoba w zespole z fusów wróżyć nie musiała. Repozytorium to ktoś otworzy trzy miesiące po Twoim odejściu. Wiedzieć musi, co autor miał na myśli, zanim robotę na taką z darmowymi owocami i lepszym biurkiem zmienił. Tylko koderem jesteś bez tego kontraktu, instrukcjami if sypiącym jak konfetti na bardzo smutnej stypie.
Baza danych to nie projekt systemu
Architektura to nie baza danych. Raz a dobrze to zapamiętaj, bo w jedną papkę juniorom te dwa pojęcia często się zlewają. Architektem nie czyni cię narysowanie trzech tabel w MySQL Workbenchu i połączenie ich kreskami. Dla dzieciaków to tylko ciasna piaskownica. Gdy w system walnie 50 tysięcy zapytań na sekundę z prędkością karabinu maszynowego, prawdziwa zabawa się zaczyna. Błędy pluć zacznie baza szybciej, niż ty „rollback” zdążysz powiedzieć, jeśli pulę połączeń olałeś i wszystko jak leci joinujesz. Sposób, w jaki te dane oddychają, to architektura, a nie to, czy 30 czy 60 znaków ma pole username.
| Cecha | Porządny Monolit | Mikroserwisowy Obłęd |
| — | — | — |
| Opóźnienia | Prawie zerowe (wywołania funkcji) | Wysokie (sieć, serializacja JSON) |
| Debugowanie | Proste (jeden stack trace) | Koszmarne (śledzenie logów w 10 miejscach) |
| Koszty | Przewidywalne | Zależne od humoru dostawcy chmury |
Legendy już krążą o tych nieszczęsnych mikroserwisach w budce z kebabem. Wepchnęliśmy tam 12 kontenerów, bo starociem i nudą monolit nam śmierdział. Tragiczny był efekt. Trzy sekundy bite trwało pobranie listy sosów. Autoryzację, serwis stanów i osobną bazę dodatków zaliczyć musiał każdy request o sos czosnkowy. O propagacji kontekstu zapomnieliśmy, więc bardziej niż błąd kompilacji C++ o trzeciej nad ranem bolało debugowanie tego ścieku w logach. Pod ciężarem JSON-ów sieć nam po prostu zdechła. Na samo jałowe gadanie usług między sobą marnowaliśmy 40% zasobów. Bez mrugnięcia okiem te mikro-cuda zaorałem. System nagle jak po reanimacji ożył – jeden prosty monolit, stara baza, dwa JOIN-y. Warunki dyktować musi skala projektu. Zwykły kretynizm projektowy pod płaszczykiem nowoczesności inaczej uprawiasz.
Finansowe harakiri przez PDF-y
Częściej, niż myślisz, zdarza się finansowe samobójstwo przez dokumentację. Projekt w fintechu z budżetem 480 000 zł widziałem. Na dokumentację funkcjonalną poszło z tego 110 000 zł, a na „rozszerzoną analizę przypadków brzegowych” 62 000 zł. Development z nudów stał i kwiczał. 147 scenariuszy logowania zdążyli opisać analitycy, zanim backend w Javie pierwsze zadanie dostał. W tym taki, w którym użytkownik zmienia przeglądarkę, dwa VPN-y ma włączone i jazzu słucha w trakcie resetu hasła. Serio, nikt tego nie czytał. Instrukcją obsługi ma być dokumentacja, a nie epopeją narodową.
Większa iluzja kontroli nad chaosem pojawia się, im grubszy jest PDF. Ryzyko obniża specyfikacja na 220 stron? Dokładnie odwrotnie jest. Na interpretację zapisu o „elastycznych scenariuszach rabatowych” zespół trzy sprinty traci. Co to w ogóle znaczy? Kwotowy czy procentowy rabat? Silnik w Drools czy reguły w bazie? Od humoru architekta to zależy. I najwięcej kosztuje właśnie to „zależy”. Ogromny koszt poznawczy generują za długie dokumenty. 40 minut junior czyta, a potem o kody błędów i tak na Slacku pyta. Sygnał, że za słowa, a nie za realną wartość dla biznesu ktoś fakturuje, to specyfikacja powyżej 80 stron dla średniego projektu.
Definicja ekspercka: Architektura to moment, w którym Twoje założenia lądują na stole. README, prosty diagram w draw.io, czasem C4 Model. Nie forma ma znaczenie, tylko treść. Redukowanie niejednoznaczności to jej jedyna robota.
Od dekad kołem historia się toczy. Nad „software crisis” mądrale płakały już w 1968 roku na konferencji NATO. Bo projekty trzy razy szybciej budżet przekraczały, niż kod powstawał, padło to hasło w Garmisch-Partenkirchen. W pył harmonogramy się rozpadały. Własnym życiem żył kod pisany w Fortranie, papierowe analizy totalnie ignorując. Naiwnie myśleli, że wszystko naprawią metody inżynierskie. Reacta, Springa i ORM-y generujące zapytania SQL dłuższe niż twoje całe CV masz dziś. Ale prosto w twój monitor śmieją się duchy z 1968 roku, jeśli nie kumasz, dlaczego wydajność zabija N+1 query. Pobierasz listę 100 autorów, a potem dla każdego z nich osobno pytasz bazę o książki. Gratulacje, 101 zapytań właśnie wysłałeś tam, gdzie wystarczyło jedno porządne połączenie.
Mapy Google dla koderów
Żebyś w myślach kolegów czytać nie musiał, wymyślono zasady Kruchtena i model C4. Jeden obrazek w PowerPoincie zrobiony na kolanie to nie jest architektura. O tym samym systemie to kilka różnych opowieści. Inaczej z DevOps-em rozmawiasz, inaczej z backendowcem. Widok logiczny, procesowy, fizyczny i developerski dał nam Kruchten. Skalę jak Google Maps porządkuje C4. Od kontekstu (widok całego miasta) do kodu (numer mieszkania z krzywą wycieraczką). Ale śmiertelną pułapką bywa to ostatnie powiększenie.
Implementację opisujesz, a nie architekturę, gdy poziom kodu rysować zaczynasz. Klasy z IDE pokazujesz, które jutro skasujesz, zamiast granic odpowiedzialności. Inaczej to i tak za trzy sprinty będzie wyglądać. Z diagramem zostaniesz, który wartość sentymentalną i absolutnie zero operacyjną ma. Gorsze zło niż całkowity brak to dokumentacja przeterminowana. Gdzie jeden moduł się kończy, a zaczyna drugi – to ma mówić architektura. Po jakim protokole i kto z kim gada. Domena repozytorium i rygorystycznego code review to klasy i metody, nie diagram dla 12-osobowego zespołu, który go i tak nie otworzy.
W poniedziałek rano jak to ugryźć bez bólu głowy? Brzytwą niejednoznaczność architektura wycinać musi. Tyle papieru wystarczy, ile koledze bez dzwonienia do ciebie w trakcie Twojego urlopu w Egipcie funkcję napisać pozwoli. Na granicach modułów się skup. Jeśli jeden klockek na inny wymienisz, co wybuchnie? Pola minowego z „quick fixów” nie buduj. Dymiace pole bitwy masz, nie projekt, jeśli 70% twoich commitów to „poprawka na szybko”. Szybciej niż PowerPoint zmienia się kod. Z tym się pogódź.
Kontrakt społeczny zamiast magii
Wątpliwość tu się pojawia: czy kontrolujesz w ogóle to, co piszesz? Tylko ograniczenie jego artystycznej wolności – tak junior często o architekturze myśli. „Zmienić można to później” – naiwni mówią. Można, ale dla budżetu matematyczna rzeźnia to każda zmiana interfejsu przy 50 klientach. Kontrakt społeczny to architektura. Czytelnie ma być, nie literacko. Rozmowę w zespole zabija zbyt precyzyjny opis. Coś prostszego zaproponować junior się boi, bo „inaczej jest w dokumencie”. Ktoś pisał dokument, kto ograniczeń ORM-a na oczy nie widział. Tylko w urzędzie skarbowym papier z rzeczywistością wygrywa.
Po co to wszystko robimy? Żebyś szefa w myślach czytać nie musiał. Tłumaczyć trzy razy tej samej prostej funkcji żeby Product Owner nie musiał. Sakramentalne: „Inaczej myślałem, że to działa” żeby na daily nie padało. Jednoznaczna umowa to architektura. W zbiór lokalnych interpretacji bez niej projekt się zamienia, a szybciej niż liczba Twoich commitów dług techniczny rośnie. I tylko cudze domysły będziesz wtedy odkręcać zamiast nowe funkcje pisać.
O twarde zasady zadbaj, zamiast gonić za kolejnym frameworkiem. Z przekombinowaniem w 9 na 10 przypadków prostota wygrywa. Redukowanie niepewności to architektura, nie rysowanie strzałek dla zabawy. Jedna strona README z jasno określonymi zasadami gry czasem wystarczy. Święte muszą być te zasady. Inaczej spłonie Twój kod, a Ty razem z nim, deadline’y goniąc, których nawet w alternatywnej rzeczywistości dotrzymać się nie da.
Autor: programista z 15 letnim doswiadczeniem, expert, redaktor z zacieciem do pisania lekkich i zartobliwych tekstow
Chciałbyś, abym zaprojektował dla Ciebie prosty kontrakt komunikacyjny dla Twojego obecnego projektu?
Leave a Reply