Refaktoryzacja czy przepisanie kodu: jak wybrać trafnie?

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.

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.

Refaktoryzacja zwykle daje szybszy efekt, jeśli zakres jest dobrze zawężony. Rewrite potrafi wygrać dopiero wtedy, gdy nowy rdzeń startuje na wąskim, ale wartościowym przepływie i nie czeka roku na „pełną gotowość”. Jeśli pierwszy etap nie dowozi produkcyjnej wartości, projekt zaczyna żyć własnym życiem i szybko traci polityczne wsparcie.

Najbardziej niedoszacowany koszt rewrite nie siedzi w kodzie, tylko w danych. Historia korekt, wyjątki księgowe, niestandardowe statusy, ręczne obejścia w operacji i raporty budowane pod konkretne decyzje biznesowe wracają później ze zdwojoną siłą. Zespół, który mówi „przepiszemy logikę, a dane się przeniesie”, zwykle jeszcze nie wie, ile naprawdę ma do przeniesienia.

Po stronie refaktoryzacji ryzyko też jest realne. Jeśli organizacja nie zmieni sposobu pracy, dług techniczny wróci. Bez testów, dyscypliny wdrożeń i lepszych granic modułów nawet dobrze rozpoczęta poprawa zamieni się w serię lokalnych porządków bez trwałego efektu.

Warto policzyć trzy rzeczy osobno. Po pierwsze, koszt dojścia do pierwszej wartości produkcyjnej. Po drugie, koszt współistnienia starego i nowego rozwiązania. Po trzecie, koszt błędu po przełączeniu, zwłaszcza gdy dotyczy rozliczeń, zamówień albo danych klienta. Dopiero suma tych trzech pozycji pokazuje, czy rewrite ma sens ekonomiczny.

Jeżeli firma nie potrafi wskazać, które raporty muszą zgadzać się dzień po dniu po migracji, to nie jest jeszcze gotowa na ambitne przepisanie rdzenia. W takim momencie bezpieczniej inwestować w ograniczenie promienia zmian i poprawę testowalności niż w projekt, którego ryzyka nikt nie umie nazwać.

Trzy use case'y, które naprawdę rozdzielają decyzję

Zamiast sporu ideologicznego lepiej patrzeć na przepływy, które firma wykonuje codziennie. To one pokazują, czy problemem jest jakość zmiany, czy sam kształt systemu.

System sprzedażowy działa, ale zmiany są bolesne. Firma handlowa ma stabilny model przychodów, lecz każda zmiana w promocjach i cennikach trwa tygodniami. Integracje działają, dane są względnie spójne, a problemem jest głównie ryzyko regresji. Tu refaktoryzacja wygrywa, bo biznes nie potrzebuje nowego rdzenia. Potrzebuje szybszego i bezpieczniejszego dostarczania zmian.

W takim scenariuszu sensowny plan wygląda prosto: najpierw testy regresji dla cenników i rabatów, potem wydzielenie logiki cenowej, a dopiero później porządki w warstwie technicznej. Jeśli zespół zacznie od wymiany całego stosu, prawdopodobnie przez miesiące nie poprawi ani jednej rzeczy, którą realnie odczuwa dział sprzedaży.

Firma przechodzi na nowy model rozliczeń. Dostawca oprogramowania chce przejść z jednorazowych licencji na subskrypcję z rozliczeniem użycia i portalem samoobsługowym. Stary system zakłada jeden typ klienta, jeden cykl fakturowania i ręczne korekty. Tu rewrite albo wymiana rdzenia ma sens, bo ograniczeniem nie jest bałagan w kodzie, tylko stary model domeny.

Kluczowe jest jednak zawężenie pierwszego wdrożenia. Nie trzeba od razu przenosić wszystkich klientów. Rozsądniej uruchomić nowy model dla nowej grupy odbiorców albo nowego produktu, a starych klientów migrować dopiero po potwierdzeniu rozliczeń, raportów i obsługi wyjątków.

Technologia jest wspierana słabo albo wcale. System nadal obsługuje procesy, ale działa na komponentach bliskich końca wsparcia, a zespół ma coraz większy problem z utrzymaniem i rekrutacją. Jeśli do tego dochodzą wymagania bezpieczeństwa lub zgodności, dalsze łatanie staje się ryzykowne. W takim układzie decyzja często przesuwa się w stronę rewrite lub etapowej wymiany rdzenia, nawet jeśli biznes nie zmienia jeszcze modelu działania.

Tu trzeba uważać na fałszywy skrót myślowy: brak wsparcia technologii nie zawsze oznacza, że trzeba wymienić wszystko. Czasem wystarczy odseparować najbardziej ryzykowną część, unowocześnić warstwę integracyjną albo przenieść krytyczne funkcje do nowego komponentu. Pełny rewrite jest uzasadniony dopiero wtedy, gdy ryzyko technologiczne łączy się z problemem domenowym albo operacyjnym.

Bardziej konkretny przykład niż anonimowe „firma z branży B2B”: zespół utrzymujący system zamówień i rozliczeń odkrył, że większość pilnych zgłoszeń wraca po zmianach w rabatach i synchronizacji z ERP. Nie po całym systemie. Po jednym fragmencie. Zamiast przepisywać wszystko, osłonili logikę cenową testami, wydzielili reguły rabatowe i dołożyli monitoring zdarzeń między zamówieniem a księgowaniem. Po kilku iteracjach liczba pilnych poprawek spadła, a temat pełnego rewrite stracił impet. Nie dlatego, że system nagle stał się piękny. Po prostu przestał blokować biznes tam, gdzie bolało najbardziej.

O decyzji przesądziły tu konkretne przepływy i koszt migracji, nie estetyka kodu. Gdy źródło incydentów zawęziło się do logiki rabatowej i integracji z ERP, pełny rewrite przestał mieć ekonomiczny sens.

Kiedy zrobić audyt przed decyzją

Nie każda firma potrzebuje od razu partnera zewnętrznego. Audyt ma sens wtedy, gdy zespół nie umie odpowiedzieć na kilka prostych pytań: które procesy naprawdę zarabiają, gdzie jest źródło prawdy dla danych, które integracje muszą działać bez przerwy i jak sprawdzić zgodność raportów po przełączeniu.

To powinno być krótkie rozpoznanie wykonawcze, nie prezentacja dla zarządu.

Przed taką diagnozą dobrze przygotować:

• listę krytycznych procesów z perspektywy przychodu, operacji i zgodności,
• mapę integracji z oznaczeniem zależności czasowych i finansowych,
• informację o wsparciu technologii dla runtime, baz danych i kluczowych komponentów,
• zestaw problemów po wdrożeniach, zwłaszcza incydentów, rollbacków i obszarów o największym promieniu rażenia,
• próbkę raportów i rozliczeń, które muszą zgadzać się po migracji.

Jeśli tych danych nie ma, decyzja o rewrite jest zwykle przedwczesna. Jeśli są, można szybko odróżnić problem jakości kodu od problemu architektury i domeny.

W projektach z dużą liczbą integracji pomagają testy kontraktowe i obserwowalność oparta o OpenTelemetry. Nie dlatego, że to modne. Bez nich modernizacja bywa częściowo ślepa. Gdy po zmianie nie zgadzają się statusy płatności albo eksporty do finansów, biznes nie będzie dociekał, czy zawiódł stary czy nowy komponent.

Dobry audyt kończy się nie rekomendacją „przepisać” albo „refaktoryzować”, tylko listą decyzji wykonawczych. Który przepływ ruszyć pierwszy. Jak zmierzyć sukces. Jakie dane porównywać równolegle. Kto odpowiada za migrację. Kiedy przerwać projekt, jeśli założenia przestają się spinać. Bez tego nawet trafna diagnoza nie zamienia się w bezpieczny plan.

Jeżeli po diagnozie wychodzi, że trzeba wymieniać rdzeń etapami, naturalnym kolejnym krokiem jest modernizacja systemów legacy z jasno określonym pierwszym zakresem. Bez obietnicy, że wszystko da się przełączyć jednym ruchem.

Najczęstsze błędy przy wyborze ścieżki

Pierwszy błąd to traktowanie jakości kodu jako jedynego kryterium. Kod może być brzydki, a system nadal dobrze wspierać biznes. Może też być względnie czysty, a mimo to blokować nowy model działania. Decyzja nie dotyczy estetyki repozytorium.

Drugi błąd to ignorowanie danych i migracji. W wielu systemach prawdziwa złożoność nie siedzi w ekranach ani API, tylko w historii rekordów, wyjątkach księgowych, korektach i zależnościach raportowych. Kto tego nie uwzględnia, ten zaniża koszt rewrite już na starcie.

Trzeci błąd to brak właściciela przejścia. Nie wystarczy zespół programistyczny. Potrzebna jest osoba albo mała grupa, która pilnuje zgodności danych, kolejności migracji, kryteriów akceptacji i decyzji o przełączeniu. Bez tego projekt dryfuje między technologią a operacją.

Czwarty błąd jest bardziej polityczny niż techniczny: firmy uruchamiają rewrite, żeby symbolicznie odciąć się od starego systemu. To zły powód. Jeśli nowy projekt ma być terapią dla frustracji zespołu, a nie odpowiedzią na blokadę biznesową, rachunek przyjdzie szybko.

Najrozsądniejsza rekomendacja brzmi mniej efektownie niż hasła o nowym starcie. Gdy system nadal pasuje do biznesu, zacznij od audytu przepływów, testowalności i kosztu przejścia. Gdy rdzeń przestał mieścić sposób zarabiania albo technologia weszła w strefę realnego ryzyka, przygotuj wąski pierwszy zakres nowego rozwiązania zamiast kopiować cały stary świat. Wyjątek istnieje: czasem nawet źle dopasowany system da się jeszcze chwilowo utrzymać, jeśli firma potrzebuje krótkiego okna na zmianę modelu operacyjnego. Tyle że takie odroczenie ma sens tylko wtedy, gdy ktoś świadomie liczy jego cenę.