W większości przypadków odpowiedź brzmi: migrować stopniowo, nie przepisywać od zera. Przepisanie całości (big bang rewrite) świetnie wygląda na slajdzie, ale w praktyce oznacza lata pracy, zamrożenie rozwoju biznesowego i realne ryzyko, że nowy system nigdy nie dogoni starego. Podejście strangler fig – stopniowe zastępowanie fragmentów starego systemu nowymi, aż stary „obumrze” – pozwala na modernizacje w locie, bez zatrzymywania biznesu i z możliwością wycofania się na każdym etapie. Rewrite bywa uzasadniony, ale rzadziej niż się wydaje. Poniżej wyjaśniamy, kiedy który wariant ma sens i co musi być spełnione, żeby migracja stopniowa faktycznie się udała.
Dwa mity, które zaciemniają decyzję
Rozmowa o modernizacji zwykle grzęźnie na dwóch fałszywych założeniach. Pierwsze: „ten system jest nie do uratowania, trzeba wszystko przepisać”. Drugie, przeciwne: „działa, więc nie ruszamy”. Oba są pułapkami.
Pierwsze prowadzi do kosztownej rewolucji, która zbyt często kończy się przekroczonym budżetem i porzuconym projektem. Drugie ignoruje fakt, że dług technologiczny nie stoi w miejscu – rośnie ryzyko awarii, znika wiedza o systemie, a wymogi takie jak DORA zaczynają wymagać rzeczy, których na starym, nieudokumentowanym stacku po prostu nie da się wykazać. Prawdziwy wybór nie brzmi „przepisać albo nic nie robić”. Brzmi „jaką ścieżką modernizować, żeby nie zatrzymać biznesu”.
Dlaczego big-bang rewrite tak często zawodzi
Przepisanie całego systemu od zera ma kilka wbudowanych wad, które ujawniają się dopiero w trakcie.
Zamrożenie funkcjonalności. Przez miesiące, a częściej lata, nowy system nie ma parytetu funkcji ze starym. Biznes czeka, a konkurencja nie. To najkosztowniejszy, choć niewidoczny w budżecie, wydatek rewrite’u.
Ukryta logika, której nikt nie spisał. Stary system zawiera setki reguł biznesowych wypracowanych latami – w Delphi, VB6 czy starej Javie EE. Przepisując „na czysto”, łatwo je zgubić, bo nie ma ich w żadnej dokumentacji, tylko w kodzie. Efektem bywają subtelne błędy, które wychodzą dopiero na produkcji.
Efekt drugiego systemu. Zespół, który dostaje szansę „zrobić to wreszcie dobrze”, ma naturalną skłonność do przeprojektowania i dołożenia funkcji, których nikt nie potrzebuje. Zakres puchnie, a termin się oddala.
Jeden wielki punkt przełączenia. Migracja „wszystko naraz” oznacza jeden dzień, w którym cały ruch przechodzi na nowy system. To jednocześnie jeden wielki punkt awarii, bardzo trudny do bezpiecznego wycofania.
Na czym polega strangler fig
Nazwa pochodzi od figowca dusiciela, który stopniowo oplata drzewo, aż to obumiera. W modernizacji IT działa to tak: nową funkcjonalność budujecie wokół starego systemu i przekierowujecie do niej ruch fragment po fragmencie. Fasada lub warstwa routingu decyduje, czy dane żądanie obsłuży stary, czy nowy komponent. Z czasem coraz więcej trafia do nowego, aż stary system można w końcu wyłączyć.
Dwa elementy są tu kluczowe. Fasada, która kontroluje przepływ ruchu i pozwala przełączać go stopniowo. Oraz warstwa antykorupcyjna (anti-corruption layer), która tłumaczy między modelem starego systemu a nowym, tak żeby nowy kod nie odziedziczył wszystkich wad poprzednika.
Zaleta jest zasadnicza: wartość dostarczacie przyrostowo, ryzyko rozkłada się na wiele małych kroków, a na każdym etapie da się wycofać. Biznes cały czas działa, bo nigdy nie ma momentu „wielkiego przełączenia”.
Warunki, bez których migracja stopniowa się nie uda
Strangler fig nie jest magią. Ma kilka twardych warunków wstępnych.
Zrozumienie tego, co przenosicie. Nie da się bezpiecznie „stranglować” systemu, którego nikt nie rozumie. Podstawą jest aktualna dokumentacja architektury oraz inwentaryzacja procesów, która pokazuje, które funkcje są krytyczne i jak systemy są ze sobą powiązane. Bez tego przenosicie logikę w ciemno.
Wyodrębnialne szwy. Musi dać się wydzielić moduły albo domeny, które można zastępować niezależnie. Metoda Event Storming pomaga wyznaczyć te granice zgodnie z rzeczywistymi procesami, a nie przypadkowym podziałem kodu.
Testowalność i kontrola ruchu. Żeby bezpiecznie przełączać fragmenty, potrzebujecie pokrycia testami i możliwości sterowania tym, co trafia do starego, a co do nowego komponentu.
Dyscyplina. Największe ryzyko strangler fig to zostawienie „tymczasowego” dualizmu na zawsze. Migracja musi mieć jasny cel końcowy: wyłączenie starego systemu, a nie utrzymywanie dwóch w nieskończoność.
Kiedy rewrite jednak ma sens
Przepisanie od zera bywa właściwym wyborem, ale w wąskich sytuacjach. Gdy platforma lub technologia nie ma już wsparcia i nie da się jej sensownie zintegrować z nowym kodem. Gdy system jest na tyle mały, że przepisanie kosztuje mniej niż okablowanie stopniowej migracji. Albo gdy zmienia się fundamentalnie model biznesowy i stare reguły i tak trafią do kosza.
Nawet wtedy obowiązuje jedna zasada: najpierw odtwórzcie wiedzę o starym systemie. Inaczej przepiszecie go, gubiąc reguły, które właśnie decydowały o tym, że działał.
Jak zdecydować
Praktyczny skrót jest prosty. Zacznijcie od widoczności – co dokładnie macie i które procesy są krytyczne. Oceńcie, czy system da się rozbić na wyodrębnialne fragmenty i jakie ryzyko niesie każdy z nich. Wybierzcie najmniejszy wartościowy pierwszy krok, który da się bezpiecznie przełączyć i w razie czego wycofać. Domyślną ścieżką niech będzie migracja stopniowa; rewrite traktujcie jak świadomy wyjątek, nie jak punkt startowy.
W Finture zaczynamy od odzyskania wiedzy o systemie: automatyczna, zawsze aktualna dokumentacja architektury (S*.doc) i inwentaryzacja procesów dają mapę, na której da się zaplanować bezpieczną kolejność. Na tej podstawie projektujemy i wdrażamy modernizację jako rozwiązanie dedykowane, krok po kroku, bez zatrzymywania biznesu.
FAQ
Czym jest wzorzec strangler fig?
Kiedy lepiej przepisać system od zera niż migrować stopniowo?
Dlaczego big-bang rewrite jest ryzykowny?
Co jest potrzebne, żeby bezpiecznie migrować system legacy?
Czy migracja stopniowa jest wolniejsza niż przepisanie?
Zastanawiacie się, czy Wasz system w Delphi, VB6 lub starej Javie EE nadaje się do migracji stopniowej, czy jednak do przepisania? Porozmawiajmy – zaczniemy od mapy systemu, a nie od z góry przyjętej odpowiedzi.
