Paradoks architektury: Dlaczego szybki kod spowalnia cały system

Pracowałeś z asystentami AI do kodowania? Wiesz, o co chodzi. Piątek po południu wpada żądanie nowej funkcji. Do poniedziałku masz działający kod z testami. PR schludny, biznes zadowolony, deployment przed lunchem.

A po trzech miesiącach? Debugujesz koszmar, którego nikt się nie spodziewał.

Pułapka prędkości

Co się zmieniło w ostatnich latach? Pisanie kodu stało się tanie, ale architektura nie.

Narzędzia jak GitHub Copilot, Claude czy frameworki ukrywające boilerplate pozwalają developerom klepać działający kod w tempie nie do pomyślenia pięć lat temu. Biblioteki komponentów, narzędzia wewnętrzne i luźne kodowanie ułatwiają prototypy i szybkie shipowanie.

To super sprawa. Szybkie iteracje to szybka nauka. Zespoły, które testują pomysły błyskawicznie, wygrywają konkurencję.

Ale ta prędkość ma ukryty koszt.

Gdzie się podziała architektura?

Działający kod to nie kod, który pasuje do systemu. Funkcja przechodzi testy, a i tak może być bombą z opóźnionym zapłonem:

• Powtarzająca się logika, którą dało się podzielić między moduły
• Niejasne kto za co odpowiada – odpowiedzialności rozsiane po plikach
• Niespójne wzorce, przez które kod trudno ogarnąć
• Luki w bezpieczeństwie, bo liczyła się tylko dostawa
• Słabe granice między systemami – na starcie OK, w skali katastrofa
• Jednorazowe klocki, które powinny być reusable patternem
• Funkcje trudne do wywalenia, bo zaplątały się w inne

Problem? Jak te błędy wypłyną, kod jest już w mainie, w produkcji i broniony przez biznes.

Butelka szyjna przed mergem

Rozwiązanie? Zaostrzyć code review. Niech architekci i seniorzy czeszą każdy PR. Łapać problemy na wejściu.

Teoria super. Praktyka? PR-y wiszą dniami. Dyskusje po fakcie, gdy kod jest i trudno go ruszyć. Frustracja devów, którzy dostarczyli działającą ficzę, a dostają feedback do refaktoryzacji. A to zanim kolejka PR-ów zablokuje całą prędkość z AI.

Review staje się bramką, nie narzędziem jakości.

Lepszy sposób: Architektura non-stop

Nie chodzi o spowolnienie review. Chodzi o przesunięcie decyzji architektonicznych.

Zamiast łapać wszystko przed mergem, dobre zespoły budują jawne pętle feedbacku po mergu:

Przegląd systemowy: Po wylądowaniu ficzy ktoś patrzy na całość. Czy to wzorzec do kopiowania? Czy złamało granice?

Ocena reuse: Da się scalić duplikaty? Wyciągnąć pattern, który widać dopiero w skali?

Sprawdzenie security i założeń: Kod żyje – czy założenia trzymają? Edge case'y z izolacji?

Plan refaktorów: "Refaktor później" działa, jeśli jest w kalendarzu. Refaktoring jako priorytet, nie wypełniacz luk.

Feature flags i odwracalność: Shipuj za flagami. Łatwo wyłączyć. Projektuj z myślą o rewrite'ie.

Klucz: architektura to proces ciągły, nie brama.

Jak zrobić "refaktor później" realnym

To działa, gdy "później" to zobowiązanie, nie marzenie.

Zespoły z szybkim devem i zdrową architekturą mają wspólne cechy:

• Rezerwują czas na architekturę (nie czekają na downtime sprintu)
• Mierzą zdrowie systemu obok velocity ficzy
• Stopują i przepisują, gdy tech debt rośnie
• Architekci wchodzą po mergu, nie tylko przed
• Deployment szybki, refaktory nie ryzykują

Prawdziwe pytanie

Początkowe: "Gdzie robić architekturę?"

Odpowiedź: wszędzie, ale w różnych momentach.

W designie (przed kodem). W review (oczywiste błędy). Ale też po mergu, w refaktorach, redesignach i chwilach, gdy zespół mówi: "Działa, ale da się lepiej".

Narzędzia dev nie są problemem. Wyzwanie to zespoły i procesy nadążające za prędkością – bez psucia struktury systemów.

Jeśli łapiecie architekturę w komentarzach PR, walczycie z fizyką. Silnik kodowania pruje szybciej niż review.

Czas ulepszyć oba.

A u was jak? Architektura przed mergem, po, czy pośrodku? To powie, czy wasza prędkość pociągnie długo.