Audyt i architektura
Audyt PHP/Symfony/Laravel
Audyt Symfony/Laravel ma uporządkować ryzyko, pokazać kolejność działań i dać odpowiedź, czy system trzeba stabilizować, modernizować, czy po prostu bezpiecznie prowadzić dalej.
W wielu zespołach problem nie wygląda dramatycznie. System jeszcze działa, release'y jeszcze wychodzą, ale każda kolejna zmiana zaczyna kosztować więcej czasu, więcej ostrożności i więcej rozmów, niż powinna. I właśnie w takim miejscu audyt ma sens. Nie jako raport, który ocenia czyjś kod. Nie jako lista pretensji. Audyt ma pomóc podjąć decyzję: co ruszyć teraz, co zostawić w spokoju i gdzie przestać zgadywać.****
Jeśli pracujesz na Symfony albo Laravel i czujesz, że nawet mała zmiana wymaga coraz większego przygotowania, to zwykle nie jest moment na hasła o rewolucji. To jest moment na uporządkowanie ryzyka.
Systemy rzadko psują się w sposób widowiskowy. Częściej zaczyna się od drobnych sygnałów: wdrożenia trwają dłużej, każda zmiana wymaga dodatkowej ostrożności, a zwykłe pytanie o „mały fix” uruchamia trzy spotkania, dwa wątki na Slacku i ostrożne sprawdzanie, czy nic się nie rozsypie po drodze. Na tym etapie zespół jeszcze dowozi, ale już czuje, że koszt ruchu rośnie szybciej niż wartość samego ruchu.****
To właśnie jest moment na audyt. Najczęściej pojawia się po przejęciu systemu od innego zespołu, po długim odkładaniu upgrade'u PHP / Symfony / Laravel, przy rosnącej liczbie regresji albo wtedy, gdy integracje z API, cronami i synchronizacją danych zaczynają zachowywać się kapryśnie. Audyt nie jest wtedy dekoracją. Jest sposobem na to, żeby zespół przestał działać na wyczucie i zobaczył, gdzie naprawdę leży problem.****
Dobry audyt nie kończy się zdaniem: „jest trochę długu technicznego”. To jest za mało, żeby ktoś mógł po tym realnie działać. Sensowny audyt powinien pokazać kolejność, a nie tylko katalog problemów. Ma odpowiedzieć na pytanie, które elementy systemu są najbardziej wrażliwe, gdzie mała zmiana ma duży promień rażenia, co blokuje rozwój i czego nie warto ruszać, dopóki nie zostanie przygotowany plan.****
Najbardziej praktyczny efekt nie wygląda jak gruby dokument. Wygląda jak krótka, czytelna decyzja: co stabilizować najpierw, co można przesunąć, gdzie potrzebna jest ostrożność i czy system powinien być przede wszystkim utrzymany, uporządkowany czy modernizowany. Właśnie taka odpowiedź daje zespołowi spokój przy kolejnych krokach, bo zamiast domysłów zostaje jasna mapa ryzyka.
Audyt nie powinien być luźnym przeglądem kodu bez wyniku. Nie powinien być listą „co jest źle” bez priorytetów. Nie powinien też być pretekstem do sprzedaży rewrite'u, zanim w ogóle zostanie nazwana przyczyna problemu. Jeśli po audycie zostaje tylko ogólne wrażenie, że „coś trzeba będzie z tym zrobić”, to taka praca nie redukuje niepewności. A właśnie po to audyt się robi.****
To nie jest tylko intuicja. W badaniu Stripe The Developer Coefficient średnio 13,5 godziny tygodniowo przypadało na pracę z technical debt, a 52% respondentów wskazywało utrzymanie legacy systemów jako czynnik hamujący produktywność. Z kolei w raporcie DORA 2018 elite performers mieli 7x niższy change failure rate i 2 555x szybszy lead time niż low performers. Te liczby nie mówią, że każdy system trzeba przepisać. Mówią coś bardziej praktycznego: jakość decyzji operacyjnych realnie wpływa na tempo i stabilność dostarczania.****
Dlatego audyt powinien kończyć się odpowiedzią na bardzo konkretne pytania: gdzie ryzyko jest największe, co ma priorytet, co można odłożyć i czego lepiej nie ruszać bez przygotowania. Bez tego nawet dobry przegląd techniczny łatwo zamienia się w opowieść bez konsekwencji.
Po audycie powinien zostać dokument, który naprawdę pomaga podjąć decyzję. Nie prezentacja dla samej prezentacji. Nie raport, który brzmi mądrze, ale niczego nie porządkuje. Tylko coś, co da się wykorzystać od razu.1. krótka lista priorytetów2. mapa ryzyk3. plan dalszych działań4. jasne założenia i ograniczenia5. rekomendacja, czy stabilizować, modernizować, czy iść dalej
To jest szczególnie ważne w firmach, które przejęły system po vendorze, walczą z zaległym upgrade'em albo próbują rozwijać produkt mimo tego, że każdy release kosztuje coraz więcej energii. W takich miejscach prawdziwą wartością audytu nie jest sama diagnoza. Wartością jest to, że po audycie zespół wie, co robić najpierw.
Audyt nie musi być końcem współpracy. Jeżeli po przeglądzie okazuje się, że warto iść dalej, można przejść do wdrożenia rzeczy, które wyszły jako najważniejsze. Tyle że to powinien być już osobny etap, uruchamiany dopiero wtedy, gdy decyzja jest podjęta. Najpierw porządek w ryzyku, potem praca. Zwykle to zdrowsza kolejność niż zaczynanie od wdrażania wszystkiego naraz.****
Jeżeli system Symfony/Laravel działa, ale każda zmiana zaczyna kosztować coraz więcej, audyt bywa najlepszym pierwszym krokiem. Nie dlatego, że rozwiązuje wszystko. Tylko dlatego, że daje coś znacznie rzadszego: sensowną kolejność działania. A w praktyce to właśnie ona najczęściej decyduje o tym, czy zespół odzyskuje spokój, czy dalej brnie w zgadywanie.