Refaktoryzacja czy rewrite to nie jest wybór między „starym” a „nowym”, tylko między dwiema klasami ryzyka. W większości firm pełne przepisanie systemu jest przeceniane, bo daje psychologiczne poczucie nowego startu, ale nie usuwa najdroższych problemów przejścia: migracji danych, odtwarzania wyjątków biznesowych i równoległego utrzymania dwóch światów. Jeśli stary system nadal obsługuje model przychodów, zwykle lepiej odzyskać kontrolę nad zmianą niż sponsorować ambitny reset.
Najdroższy błąd brzmi nowocześnie: „zróbmy to od nowa, tym razem dobrze”. Tyle że nowy kod bardzo często dziedziczy stare wyjątki procesowe, niejawne reguły rozliczeń i bałagan w danych. Nowe repozytorium nie usuwa kosztu migracji danych, odtworzenia historycznych wyjątków ani miesięcy równoległego utrzymania starego i nowego obiegu, więc budżet rośnie szybciej, niż rośnie realna wartość produkcyjna.
Refaktoryzacja czy rewrite: model decyzji, który wystarcza
Nie potrzeba rozbudowanej macierzy z dwudziestoma kryteriami. W firmach, które naprawdę muszą zdecydować, liczą się cztery pytania: czy system nadal wspiera model biznesowy, czy da się bezpiecznie zmieniać krytyczne ścieżki, czy technologia pozostaje wspierana i czy organizacja udźwignie koszt przejścia.
| Obszar | Refaktoryzacja | Rewrite |
|---|---|---|
| Model biznesowy | System nadal obsługuje główne procesy bez stałych obejść | Rdzeń nie mieści nowych rozliczeń, kanałów sprzedaży lub ról |
| Zmienialność | Da się osłonić testami krytyczne przepływy i ograniczyć promień zmian | Każda zmiana narusza wiele obszarów, a skutki są trudne do przewidzenia |
| Technologia | Stos jest stary, ale wspierany i operacyjnie bezpieczny | Kluczowe komponenty są po końcu wsparcia albo blisko tego momentu |
| Koszt przejścia | Firma nie chce długiego współistnienia dwóch światów | Organizacja akceptuje migrację danych, porównywanie raportów i etapowe przełączenia |
Jeśli po stronie rewrite wypadają dwa mocne sygnały, a jednym z nich jest niedopasowanie do modelu biznesowego albo koniec wsparcia technologii, pełne przepisanie przestaje być ekstrawagancją. Jeśli system dalej zarabia, a zespół głównie męczy słaba testowalność i lokalne sprzężenia, rewrite bywa po prostu zbyt szeroką odpowiedzią.
Do oceny zdolności dostarczania zmian dobrze nadają się wskaźniki DORA, opisane przez Google Cloud i zespół DORA: częstotliwość wdrożeń, czas wdrożenia zmiany, czas przywrócenia działania i odsetek nieudanych zmian. To nie daje automatycznej odpowiedzi, ale szybko pokazuje, czy problem siedzi w architekturze, czy w sposobie pracy zespołu. Przy ryzyku technologicznym trzeba sprawdzić oficjalne harmonogramy wsparcia producenta, choćby politykę wsparcia .NET.
Jeśli nie umiesz policzyć kosztu przejścia, nie masz decyzji. Masz tylko preferencję.
Jest jeszcze piąte pytanie, którego zespoły regularnie unikają: czy naprawdę rozumiemy obecny system. Nie chodzi o diagramy. Chodzi o wiedzę, które wyjątki są historycznym śmieciem, a które chronią przychód, zgodność albo relacje z klientami. Rewrite bez tej wiedzy nie upraszcza rzeczywistości. On tylko resetuje pamięć organizacji.
W zespołach, które utrzymują system obsługujący główne zamówienia i potrafią wskazać kilka krytycznych przepływów możliwych do osłonięcia testami, częściej wygrywa refaktoryzacja. Inaczej wygląda sytuacja, gdy nowe inicjatywy biznesowe regularnie rozbijają się o model danych, uprawnienia albo sposób rozliczeń. Wtedy dalsze łatanie zaczyna przypominać finansowanie długu technicznego kartą kredytową, a rozmowa o nowym rdzeniu przestaje być fanaberią.
Kiedy refaktoryzacja wygrywa w codziennej pracy
Najczęściej wygląda to mało efektownie: system nadal sprzedaje, ale każda zmiana w cennikach albo rabatach ciągnie za sobą ręczne testy, opóźnione wdrożenie i nerwowy rollback po publikacji. Zespół boi się ruszać zamówienia, rozliczenia i promocje, bo promień rażenia zmian jest większy niż sama funkcja.
To zwykle jest moment, w którym trzeba odzyskać kontrolę nad zmianą przez testy regresji na krytycznych ścieżkach, skrócenie czasu wdrożeń i ograniczenie rollbacków, a nie uruchamiać rewrite tylko dlatego, że kod od dawna irytuje zespół.
Refaktoryzacja ma przewagę wtedy, gdy da się zrobić trzy rzeczy: osłonić testami krytyczne przepływy, dołożyć podstawową obserwowalność i wydzielić jeden obszar o wysokiej częstotliwości zmian. Bez tego rozmowa o nowej platformie bywa ucieczką od prostszej pracy, której zespół i tak nie ominie.
Dobry punkt startu jest zwykle bardzo konkretny: moduł cenowy albo logika naliczania rabatów w firmie handlowej, gdzie błędy szybko uderzają w marżę. Jeśli po dwóch lub trzech iteracjach spada liczba incydentów, skraca się czas przygotowania zmiany i rollback przestaje być dramatem, sygnał jest czytelny. System nadal nadaje się do etapowej poprawy.
W organizacjach sprzedażowych z kilkudziesięcioma integracjami i sezonowymi pikami ruchu pełny rewrite modułu zamówień potrafi zablokować rollout na wiele miesięcy nie przez sam kod, tylko przez konieczność równoległego porównywania raportów, korekt rozliczeń i pilnowania zgodności danych między starym a nowym obiegiem. To właśnie koszt przejścia najczęściej rozwala harmonogram.
Ten wzorzec wraca zaskakująco często: organizacje mylą wolne dostarczanie zmian z koniecznością wymiany platformy. Źródłem problemu bywa brak testów regresji, słabe granice modułów i ręczne procedury wdrożeniowe. Sama zmiana frameworka tego nie naprawi.
Refaktoryzacja wygrywa też wtedy, gdy problem skupia się w kilku gorących punktach, a nie rozlewa po całym systemie. Jeśli większość incydentów pochodzi z dwóch obszarów, rozsądniej naprawić te obszary niż sponsorować wieloletni projekt wymiany wszystkiego. Mniej widowiskowe. Zwykle dojrzalsze operacyjnie.
Widziałem kilka zespołów, które chciały przepisać całość, bo „kod jest nieczytelny”. Po dwóch tygodniach wspólnego przeglądu wychodziło, że prawdziwy problem siedzi w procesie wydawniczym: brak automatycznych testów dymnych, brak środowiska z danymi zbliżonymi do produkcji i ręczne kroki wdrożeniowe wykonywane przez jedną osobę. Taki układ boli, ale nie uzasadnia jeszcze budowy nowego systemu.
W praktyce najbardziej przekonujący sygnał nie wygląda spektakularnie. Zespół zaczyna od jednego przepływu, na przykład rabatów albo rozliczeń korekt, dokłada testy regresji, porządkuje granice odpowiedzialności i po kilku sprintach widzi mniej awarii po wdrożeniu. To nie jest opowieść o wielkiej transformacji. To jest odzyskanie przewidywalności, której biznes potrzebuje bardziej niż nowego logo na architekturze.
Tu przydaje się sensowny plan etapów, a nie deklaracja wielkiej transformacji. Jeśli trzeba rozdzielać odpowiedzialności bez dużego przełączenia, pomocny bywa plan modernizacji bez big-bangu.
Kiedy rewrite naprawdę ma sens
Są sytuacje, w których refaktoryzacja tylko odsuwa koszt w czasie. Najważniejsza pojawia się wtedy, gdy firma zmienia sposób zarabiania, a stary system powstał dla innego modelu działania. Przejście z prostych licencji do subskrypcji, dodanie samoobsługi klienta, API dla partnerów albo bardziej złożonych rozliczeń potrafi ujawnić, że problem nie siedzi już w jakości kodu, tylko w samym rdzeniu domenowym.
Jeśli każda nowa funkcja wymaga obejść, duplikacji logiki i ręcznych korekt po stronie operacji, rewrite albo głęboka wymiana rdzenia stają się racjonalne. Kod może być nawet względnie uporządkowany. To nie wystarczy, gdy podstawowe założenia systemu przestały odpowiadać temu, jak firma działa dziś.
Drugi twardy sygnał to technologia wchodząca w obszar końca wsparcia. Sam koniec wsparcia nie oznacza jeszcze, że trzeba przepisać wszystko. Zmienia jednak charakter decyzji. W grę wchodzą bezpieczeństwo, zgodność, rekrutacja i ciągłość działania. Gdy system ma krytyczne integracje z ERP, płatnościami, magazynem i finansami, odkładanie decyzji bywa droższe niż sama modernizacja.
Najgorszy wariant rewrite to budowa pełnej kopii starego systemu funkcja po funkcji. Branża nadal lubi tę narrację, bo brzmi bezpiecznie. Moim zdaniem to właśnie ona psuje większość takich projektów. Porażkę rewrite częściej powoduje zbyt szeroki zakres niż sama technologia, bo zespoły próbują odtworzyć cały stary system przed dostarczeniem pierwszej wartości produkcyjnej, a wtedy miesiące pracy mijają bez realnego sprawdzenia nowego rdzenia na żywym procesie.
Większość rewrite'ów przegrywa nie dlatego, że zespoły źle wybierają stos, tylko dlatego, że próbują odtworzyć cały historyczny bałagan przed pierwszą produkcyjną wartością. Dane Chaos Report od Standish Group są od lat krytykowane za metodologię, więc nie ma sensu robić z nich twardego dowodu. Sam wzorzec rynkowy pozostaje jednak czytelny: szeroki pierwszy etap zabija przewidywalność szybciej niż wybór języka czy frameworka.
Lepszy ruch to uruchomienie nowego rdzenia na jednym przepływie o wysokiej wartości, na przykład nowym modelu rozliczeń dla nowej grupy klientów. Wtedy nowy system zaczyna pracować produkcyjnie wcześniej, a zespół nie odtwarza mechanicznie wszystkich historycznych wyjątków.
Jest jeszcze jeden sygnał, który bywa lekceważony: koszt utrzymywania fikcji, że stary rdzeń „jeszcze wytrzyma”. Jeśli każda większa inicjatywa biznesowa kończy się obejściem, dopisywaniem wyjątków i ręcznym uzgadnianiem danych między działami, firma płaci za stary model działania przy każdej zmianie. W takim układzie refaktoryzacja może poprawić jakość kodu, ale nie odblokuje wzrostu.
Tu warto postawić niewygodną tezę: część rewrite'ów nie startuje dlatego, że są potrzebne biznesowo, tylko dlatego, że łatwiej sprzedać zarządowi obietnicę nowego systemu niż żmudną naprawę procesu dostarczania. To zły znak. Jeśli głównym argumentem jest ulga zespołu, a nie nowa zdolność operacyjna firmy, projekt zwykle zaczyna od złej motywacji.
Jak policzyć koszt i ryzyko bez rozbudowanych macierzy
Koszt developmentu to tylko początek. Przy decyzji refaktoryzacja czy rewrite dużo ważniejsze są koszty ukryte: migracje próbne, porównywanie raportów, szkolenie operacji, obsługa wyjątków po przełączeniu i okres, w którym dwa światy muszą działać równolegle.
