Wzorzec Strangler Fig (figowiec dusiciel) to strategia modernizacji, w której nowy system wyrasta wokół starego i przejmuje jego funkcje moduł po module — aż stary można bezpiecznie wyłączyć. Nazwa pochodzi od figowca, który kiełkuje na drzewie-żywicielu, oplata go korzeniami i z czasem zajmuje jego miejsce. W praktyce to najbezpieczniejszy znany sposób wymiany systemu działającego na produkcji, bez wielkiego przełączenia i bez przestoju.
Najważniejsze: Strangler Fig odwraca ryzyko przepisywania od zera — zamiast budować nowy system „obok" i przełączać się w jednym momencie, przejmujesz funkcje pojedynczo. Każdy przejęty moduł działa na nowym kodzie, każdy pozostały na starym, a całość można w każdej chwili wycofać. Wzorzec opisał Martin Fowler, a praktykę zawdzięcza systemom, które nie mogą sobie pozwolić na przestój.
Problem, który rozwiązuje ten wzorzec
Klasyczne przepisanie systemu od zera ma dwa koszmarne momenty: wielomiesięczne budowanie nowej wersji „w ciemno" oraz przełączenie produkcji, w którym wszystkie nieprzetestowane edge case'y ujawniają się naraz. Do tego dochodzi paraliż decyzyjny — dopóki nowy system nie jest gotowy, stary musi żyć i być rozwijany, więc prace idą podwójnie.
Strangler Fig usuwa oba problemy. Nowy kod wchodzi na produkcję od pierwszego dnia — obsługuje jedną funkcję, obok starej. Każde przejęcie jest małe, weryfikowalne i odwracalne. Stary system przez cały czas działa i może być wyłączany funkcja po funkcji, aż zostanie pusty. To wzorzec, który zamienia „wielki wybuch" na serię kontrolowanych kroków.
Szeroki kontekst tej strategii — miejsce w planie modernizacji, testy zabezpieczające, CI/CD — opisuję w pillarze o modernizacji legacy code.
Jak działa Strangler Fig — warstwa przechwytywania
Mechanika wzorca opiera się na warstwie pośredniej, która stoi między użytkownikiem a systemami — starym i nowym. Ta warstwa decyduje, gdzie trafia każde żądanie:
- funkcje jeszcze niezmigrowane — ruch idzie do starego systemu, bez zmian,
- funkcje przejęte — ruch idzie do nowej implementacji,
- funkcje w trakcie przełączania — ruch można dzielić (np. procent użytkowników na nowy system) i porównywać wyniki obu implementacji.
Warstwą przechwytywania może być reverse proxy (nginx), router aplikacji, API gateway albo — najczęściej w projektach PHP — sam framework nowego systemu, który dla niezmigrowanych ścieżek deleguje żądania do starej aplikacji. Kluczowa własność jest jedna: przełączenie funkcji to zmiana konfiguracji, a nie wdrożenie nowego systemu.
Wariant dla monolitów — Branch by Abstraction
Nie zawsze da się przechwycić ruch na poziomie HTTP. W monolitach, gdzie funkcje wywołują się wzajemnie wewnątrz jednego procesu, stosuje się Branch by Abstraction — wzorzec pokrewny, opisany również przez Fowlera.
- Pomysł jest taki: między wywołania starej implementacji a kod, który ich używa, wstawiasz abstrakcję (interfejs). Na początku za interfejsem stoi stara implementacja. Nową implementację budujesz obok, a przełączenie polega na zmianie konfiguracji albo flagi — bez modyfikacji miejsc wywołań. To pozwala wymieniać pojedyncze komponenty wewnątrz aplikacji, bez jej rozcinania na usługi.
W praktyce projekty mieszają oba podejścia: moduły z własnym wejściem HTTP przejmuje warstwa routingu (Strangler Fig), a komponenty wewnętrzne wymienia się przez abstrakcje (Branch by Abstraction). Techniki samej przebudowy kodu opisuję w artykule o refaktoryzacji legacy code.
Kolejność przejmowania — co migrować pierwsze
Kolejność ma większe znaczenie niż tempo. Sprawdzona heurystyka wygląda tak
- zacznij od modułu o wyraźnych granicach i realnej wartości — np. logowanie, panel klienta, jeden proces biznesowy. Pierwszy moduł ma udowodnić, że proces działa, a nie rozwiązać najtrudniejszy problem systemu,
- zostaw na później moduły splecione ze wszystkim — te wymagają najpierw rozplątania zależności,
- nigdy nie migruj równolegle dwóch modułów współdzielących transakcje — najpierw rozdziel ich granice,
- ostatni migruj rdzeń systemu — wtedy nowy system obsługuje już większość ruchu, a stary został z jedną odpowiedzialnością.
Przed pierwszym przejęciem potrzebujesz mapy zależności i testów zabezpieczających. Bez mapy nie wiesz, co od czego zależy, a bez testów nie wiesz, czy nowy moduł zachowuje się jak stary. Punkt wyjścia opisuję w artykule o audycie kodu legacy, a technikę testowania starego zachowania w artykule o testach charakterystycznych.
Pułapki, które widuję w praktyce
Strangler Fig jest bezpieczny, ale nie jest wolny od pułapek. Cztery najczęstsze
Współdzielona baza danych. Stary i nowy system przez długi czas piszą do tej samej bazy. To wymaga dyscypliny: migracje schematu muszą być kompatybilne w obie strony, a nowy kod nie może „przy okazji" zmieniać struktur, których używa stary. Docelowo każdy moduł powinien dostać własny schemat albo usługę danych.
Brak warstwy przechwytywania od początku. Jeśli przełączanie modułów wymaga zmian w nginx za każdym razem, proces zacznie się rozjeżdżać. Warstwę routingu warto zaprojektować raz, z myślą o wszystkich przyszłych przejęciach.
Zbyt duże kroki. Przejęcie „całego modułu zamówień" zamiast „składania zamówienia z płatnością online" to w praktyce przepisanie od zera w przebraniu. Krok powinien być na tyle mały, żeby dało się go wycofać w godzinę.
Brak monitoringu. Nowy moduł musi mieć logi, metryki i alerty od pierwszego dnia. Bez tego pierwszy problem zobaczysz od klientów, a nie z dashboardu.
Kiedy Strangler Fig nie jest dobrym wyborem
Wzorzec ma sens tam, gdzie system ma wyraźne moduły i musi działać bez przerwy. Są jednak sytuacje, w których jest nadmiarowy:
- system mały i prosty — taniej przepisać go w całości z testami niż budować warstwę przechwytywania,
- system bez ruchu produkcyjnego — jeśli aplikacja nie obsługuje realnych użytkowników, nie ma czego „przejmować stopniowo",
- projekt, którego celem jest wymiana technologii w jednym kroku — np. migracja na nową platformę, gdzie stare i nowe nie mogą współistnieć w tej samej domenie,
- system, którego moduły nie mają granic — najpierw trzeba je wydzielić (to projekt sam w sobie), a dopiero potem migrować.
Decyzję „refaktoryzacja modułowa, Strangler Fig czy przepisanie" warto oprzeć na audycie i porównaniu kosztów, nie na modzie technologicznej.
Strangler Fig w praktyce PHP
W ekosystemie PHP wzorzec przyjmuje konkretne formy. Laravel świetnie nadaje się na „nowy system", który stopniowo przejmuje ruch: routing deleguje niezmigrowane ścieżki do starej aplikacji (np. przez współdzieloną bazę sesji albo przekierowanie wewnętrzne), a każdy nowy moduł to zwykła implementacja w frameworku — z testami, migracjami i CI/CD.
Jeśli stare i nowe aplikacje muszą działać równolegle, kluczowe stają się dwa elementy infrastruktury: współdzielona sesja i warstwa routingu. O konfiguracji pipeline'ów i wdrożeń bez przestojów piszę w artykule o CI/CD i DevOps dla Laravel, a o wyborze wersji PHP i frameworka docelowego w przewodniku o migracji PHP.
Od wzorca do planu
Strangler Fig to narzędzie, nie plan. Plan modernizacji zaczyna się od audytu i mapy zależności, przechodzi przez testy zabezpieczające i wybór kolejności modułów, a kończy na wyłączeniu starego systemu — i to wyłączenie jest momentem, w którym modernizacja formalnie się kończy. Cały proces opisuję w przewodniku o modernizacji legacy code krok po kroku.
Najczęściej zadawane pytania
Czy Strangler Fig wymaga przepisania całego systemu?
Nie. Przejęcie funkcji po funkcji oznacza, że każda migrowana część jest pisana od nowa (albo przenoszona), ale system jako całość nigdy nie jest „przepisywany w całości" w jednym projekcie. Część modułów można przy okazji wyłączyć — okazuje się, że nie są nikomu potrzebne.
Jak długo trwa modernizacja wzorcem Strangler Fig?
Zależy od liczby modułów i ich splecenia, ale przewidywalnie — pojedyncze przejęcie to dni lub tygodnie, a cały proces dla średniego systemu rozkłada się na kwartały, z działającą produkcją przez cały czas. W przeciwieństwie do przepisania od zera postęp jest widoczny po każdym module.
Czym różni się Strangler Fig od przepisania od zera?
Przepisanie od zera buduje nowy system w całości i przełącza się w jednym momencie — duże ryzyko i długi okres bez efektów. Strangler Fig przełącza funkcję po funkcji, każdy krok jest odwracalny, a stare i nowe działają równolegle. Porównanie obu dróg rozkładam w artykule o refaktoryzacji i przepisaniu od zera.
Czy stary i nowy system mogą korzystać z tej samej bazy danych?
Mogą, ale wymaga to dyscypliny: schemat musi być kompatybilny dla obu aplikacji, a migracje planowane w obie strony. Docelowo warto dążyć do rozdzielenia danych per moduł — współdzielona baza to najczęstsze źródło problemów w trakcie migracji.