Modernizacja aplikacji PHP

Punkt wyjścia — krytyczny system, którego nikt nie mógł bezpiecznie zmieniać

Aplikacja działała na PHP 5.6 — wersji bez wsparcia bezpieczeństwa od grudnia 2018 roku. Codziennie przetwarzała dane klientów, rozliczenia i raporty, a mimo to nie miała testów, kopii zapasowych ani dokumentacji. Wdrożenia były ręczne, po FTP, po godzinach; pełny cykl od decyzji do produkcji zajmował około dwóch tygodni. Awarie zdarzały się regularnie i były diagnozowane z pamięci, bo nic nie rejestrowało faktycznego zachowania systemu. Zespół przestał prosić o zmiany — backlog pełen był funkcji, o które nikt nie śmiał się upomnieć. Tak wygląda dług techniczny, gdy dojrzeje: nie liczba w arkuszu, a biznes, który po cichu obchodzi własny system. Wątek zgodności czynił sprawę pilną: dane osobowe przetwarzane przez interpreter ze znanymi, niezałatanymi lukami to ekspozycja RODO, nie tylko niedogodność utrzymaniowa.

Dlaczego nie przepisaliśmy systemu od zera — czym naprawdę jest strategia modernizacji legacy

Odruch wobec kodu legacy to przepisanie od zera — i zwykle jest to najdroższy sposób na porażkę. Przepisanie oznacza odtworzenie lat nieudokumentowanych reguł biznesowych bez sposobu porównania nowego systemu ze starym, dopóki nie będzie za późno. Alternatywą jest strategia modernizacji: utrzymywać działanie systemu, poprawiając go weryfikowalnymi krokami. Najpierw audyt, potem siatka testów, refaktoryzacja inkrementalna, automatyzacja i monitoring. Każdy krok jest samodzielnie bezpieczny i sam w sobie daje wartość. Dokładnie tak przebiegał ten projekt — i tak działa każdy poradnik w naszym hubie modernizacji legacy. Kod legacy to zresztą nie „zły kod”: to działający kod napisany w przeszłości, noszący wartość biznesową, którą przepisanie stawiałoby na szali.

Krok 1 — audyt kodu: zmierzyć problem, zanim dotknie się czegokolwiek

Modernizacja zaczyna się od rozpoznania, nie od kodu. Przeskanowaliśmy kod narzędziem PHPCompatibility (konstrukcje usunięte lub zmienione w nowszych wersjach PHP), uruchomiliśmy PHPStan pod kątem błędów typów i wywołań, które stałyby się fatalne na docelowej wersji, i zinwentaryzowaliśmy każdą zależność przez Composer — oznaczając biblioteki porzucone, bez wydania zgodnego z PHP 8. Równolegle zmapowaliśmy środowisko uruchomieniowe: dokładną wersję PHP i rozszerzenia, ustawienia php.ini, serwer webowy (nginx), bazę danych (PostgreSQL) i użycie Redis. To odkrycie środowiska ma większe znaczenie, niż brzmi: różnice konfiguracji między środowiskami to najczęstsze źródło sytuacji „na stagingu działa, na produkcji padło”. Audyt dał listę blokerów w trzech kategoriach — do naprawy automatycznej, wymagające decyzji człowieka, do wymiany biblioteki — która posłużyła jednocześnie jako plan migracji i podstawa wyceny. Ujawnił też lukę dokumentacyjną: krytyczna wiedza istniała tylko w głowie pierwotnego programisty. Zamknęliśmy ją ustrukturyzowanymi wywiadami i spisaną mapą środowiska.

Krok 2 — testy charakterystyczne: siatka bezpieczeństwa przed pierwszą refaktoryzacją

Refaktoryzacja kodu bez testów to nie modernizacja — to hazard. Ale system legacy nie ma testów do uruchomienia, więc pierwsze zadanie testowe jest inne: testy charakterystyczne (technika opisana przez Michaela Feathersa) zapisują, co system faktycznie robi dziś — także zachowania wyglądające na błąd — dzięki czemu każda zmiana, która je modyfikuje, staje się natychmiast widoczna. Pokryliśmy najpierw krytyczne ścieżki biznesowe: logowanie, procesy klientów, rozliczenia, generowanie dokumentów i raportowanie — 15–20 testów end-to-end wyłapało zdecydowaną większość ryzyk. Działały w CI na docelowej wersji PHP od pierwszego dnia, co zamieniło aktualizację z aktu wiary w proces z jasnym kryterium akceptacji: zielone testy to warunek wdrożenia. Brak testu — brak wydania; sama ta zasada wyeliminowała model „dowiemy się od użytkowników”.

Krok 3 — refaktoryzacja moduł po module z Rector, zamiast przepisywania z rozmachem

Z siatką bezpieczeństwa w miejscu refaktoryzowaliśmy jeden moduł na raz: najpierw rozliczenia (najwyższe ryzyko), potem raportowanie, panel administracyjny i na końcu integracje. Rector wykonał pracę mechaniczną — jego zestawy reguł dla przejść między wersjami zautomatyzowały 80–90% zmian z PHP 5.6 przez 7.4 do 8.x: usunięte funkcje zastąpione, składnia zmodernizowana, przestarzałe konstrukcje wyeliminowane. Każde uruchomienie Rector przechodziło ten sam cykl: wygeneruj diff, przejrzyj, uruchom pełny zestaw testów, zatwierdź — wersja po wersji, żeby każdy błąd można było przypisać konkretnej zmianie. Porzucone biblioteki zastąpiliśmy utrzymywanymi alternatywami; tam, gdzie żadnej nie było, funkcjonalność przenieśliśmy do naszego kodu — najpierw z testami. Gdy moduł wymagał głębszej przebudowy, używaliśmy wzorca strangler fig: nowy kod rósł za tymi samymi interfejsami, a stara implementacja wciąż obsługiwała ruch — system nigdy nie był „w połowie migracji”, zawsze działał. Symfony rozważaliśmy wcześnie jako cel frameworkowy; pragmatycznym wyborem okazał się Laravel na PHP 8.4 — zgodny z umiejętnościami zespołu i istniejącą warstwą bazy danych.

Krok 4 — z FTP do CI/CD: GitHub Actions, Docker i wdrożenia odwracalne

Proces wdrożeniowy był drugą główną przyczyną awarii, więc dostał takie samo leczenie jak kod. Zbudowaliśmy pipeline w GitHub Actions: każdy push uruchamia zestaw PHPUnit, analizę statyczną i build; scalenia do main wdrażają na staging automatycznie, a wydania produkcyjne to monitorowana operacja jedną komendą. Kontenery Docker czynią staging i produkcję naprawdę identycznymi — ta sama wersja PHP, te same rozszerzenia, ta sama konfiguracja — co wyeliminowało całą klasę błędów środowiskowych. Każde wydanie ma ścieżkę rollbacku: poprzedni obraz pozostaje dostępny, migracje bazy piszemy tak, by były zgodne wstecz przez jedno wydanie, a stara wersja PHP została na serwerze do potwierdzenia stabilności. Czas wdrożenia spadł z dwóch tygodni do dwóch dni, a — co ważniejsze — wdrożenia przestały być wydarzeniami. Jenkins i Ansible były na stole; dla projektu tej skali GitHub Actions z Dockerem okazał się kombinacją pragmatyczną, z najmniejszą liczbą ruchomych części do utrzymania.

Krok 5 — monitoring: incydenty mają być alertami, nie skargami

Aplikacja bez monitoringu to system, o którego awariach dowiadujesz się od klientów. Wyposażyliśmy aplikację w New Relic (czasy odpowiedzi, wolne zapytania, wskaźniki błędów), dodaliśmy śledzenie błędów i alerty z logów oraz progi na metrykach, które liczą się dla biznesu: nieudane logowania, błędy na ścieżce płatności, głębokość kolejek w Redis, czasy odpowiedzi bazy. Ostrzeżenia o przestarzałych konstrukcjach z PHP 8 stały się listą zadań zamiast szumem — każda pozycja to małe, zaplanowane porządki, a nie przyszła awaria. Pierwszy miesiąc alertów zwrócił koszt całej warstwy monitoringu: dwa wolne zapytania znaleziono i naprawiono, zanim zauważyli je użytkownicy. Wykrywanie incydentów przeniosło się z godzin (zgłoszenia) na minuty (alerty), a wraz z nim skrócił się czas usuwania skutków.

Wyzwania po drodze — czego nie widać w planie modernizacji

Każda modernizacja legacy napotyka wyzwania, których nie widać w żadnym planie. Pierwsze: porzucone biblioteki — kilka zależności nie miało wydania zgodnego z PHP 8 i żadnej aktywnej alternatywy, więc ich funkcjonalność trzeba było odtworzyć we własnym kodzie, z testami przed wdrożeniem. Drugie: nieudokumentowane reguły biznesowe — zachowania, które wyglądały na błędy, okazywały się wymaganiami; testy charakterystyczne zamroziły je jako kontrakt, zamiast „naprawiać” po cichu. Trzecie: ryzyko kluczowej osoby — wiedza o systemie mieszkała w jednej głowie, więc równolegle z refaktoryzacją prowadziliśmy wywiady i dokumentację. Czwarte: opór przed zmianą — zespół po latach awarii bał się każdego wdrożenia; dopiero pierwsze miesiące z zielonym pipeline’em i alertami zamiast telefonów od klientów odwróciły tę postawę. Piąte: różnice środowisk — „na stagingu działa” przestało być argumentem dopiero wtedy, gdy Docker uczynił środowiska identycznymi. Te wyzwania nie znikają w żadnej metodyce — różnica polega na tym, że modernizacja etapami czyni je widocznymi i rozwiązywalnymi pojedynczo, zamiast zostawiać je ukryte w wielkim przepisaniu.

Sama migracja PHP 5.6 → 8.4 — co się zepsuło i co zyskaliśmy

Ścieżka wersji prowadziła przez punkty kontrolne — 5.6 → 7.4 → 8.x — a nie jednym skokiem przez trzy generacje, więc każdy etap miał własny cykl testów i wdrożenie. Psuło się to, co z perspektywy czasu przewidywalne, a bez przygotowania drogie: usunięte funkcje (each(), create_function(), stare rozszerzenie mysql_*, modyfikator /e w preg_replace), surowsza obsługa typów, która ciche konwersje zamieniła w błędy, przekazywanie null do parametrów nienullowalnych (deprecated od 8.1) i dynamiczne właściwości (deprecated od 8.2), na których opierało się kilka starszych bibliotek. Testy charakterystyczne wyłapały każdy z tych przypadków przed produkcją. Zyski przyszły z 8.x: kompilacja JIT, atrybuty zamiast adnotacji, enumy, promocja właściwości konstruktora i właściwości readonly — oraz mierzalny wzrost wydajności samego interpretera, dziesiątki procent na najcięższych endpointach, bez dotykania logiki biznesowej. PHP 8.4 ma pełne wsparcie do grudnia 2028, a PHP 8.5 jest już dostępne — platforma jest teraz przed roadmapą, a nie lata za nią.

Zespół — usunięcie ryzyka kluczowej osoby i utrwalenie modernizacji

Technologia była połową tego projektu; drugą połową byli ludzie. Oryginalny system zależał od jednego programisty, który go rozumiał — ryzyko kluczowej osoby, które już raz wywołało kryzys, gdy był niedostępny. Udokumentowaliśmy środowisko uruchomieniowe, spisaliśmy procedury wdrożeń i rollbacku, a przez cały czas pracowaliśmy w parach z zespołem klienta: programiści i administratorzy przechodzili przez ten sam pipeline, zamykając lukę, o którą chodzi w kulturze DevOps. Pod koniec programista klienta sam wdrażał przez pipeline, czytał alerty i planował kolejne aktualizacje modułów. Modernizacja, która zostawia zespół w tyle, nie jest skończona — przekazanie wiedzy było częścią kryteriów odbioru, nie dodatkiem.

Wyniki — przed i po, z liczbami

Dwanaście miesięcy po wydaniu ostatniego modułu: zero krytycznych awarii wobec wcześniejszych regularnych incydentów z awaryjnymi poprawkami. Czas wdrożenia skrócony z 2 tygodni do 2 dni; częstotliwość wydań wzrosła z „tylko gdy trzeba” do kilku wdrożeń w miesiącu. Koszty utrzymania niższe o 60% — zniknęła premia za umiejętności PHP 5.6 i ręczne rytuały wydawnicze. Kopie zapasowe działają automatycznie, z testowanym odtworzeniem; monitoring wykrywa anomalie w minutach. Zestaw testów, który zaczął się od 15–20 testów charakterystycznych, pilnuje dziś każdej krytycznej ścieżki — i to dzięki niemu aktualizacje zależności, wcześniej niemożliwe, są teraz rutynowym zadaniem. Tabela metryk powyżej zbiera dane przed/po z anonimizowanego projektu. Najważniejszej liczby nie ma w tabeli: backlog, o który biznes przestał pytać, znowu się rusza.

Wyniki biznesowe — wydajność, skalowalność, niezawodność i doświadczenie użytkownika

Metryki techniczne przekładają się na język biznesu. Wydajność: JIT i OPcache w PHP 8.x plus naprawa dwóch wolnych zapytań dały dziesiątki procent szybsze najcięższe ekrany — bez zmiany logiki biznesowej. Skalowalność: kontenery Docker i kolejki Redis pozwalają skalować aplikację poziomo wtedy, gdy rośnie ruch, zamiast wymieniać serwer „na większy”. Niezawodność: zero krytycznych awarii przez 12 miesięcy to nie tylko brak strat wizerunkowych — to również koniec nadgodzin przy awaryjnych poprawkach i przewidywalny SLA dla klientów końcowych. Doświadczenie użytkownika: modernizacja odbyła się przy zachowaniu pełnej zgodności funkcji (feature parity) — użytkownicy nie zobaczyli migracji, a zaczęli odczuwać szybsze działanie systemu; formularze i raporty odpowiadają zauważalnie szybciej. Wzrost: odmrożony backlog oznacza nowe funkcje i nowe przychody zamiast kolejnego roku utrzymywania status quo. Modernizacja legacy to zatem nie projekt techniczny — to inwestycja we wzrost: koszty utrzymania niższe o 60%, wdrożenia z 2 tygodni do 2 dni i platforma gotowa na kolejne lata rozwoju.

Kiedy modernizacja się opłaca — i jak zacząć

Sygnały są spójne w projektach legacy: wersja PHP po zakończeniu wsparcia, brak testów, ręczne wdrożenia, awarie diagnozowane z pamięci i wiedza skupiona w jednej osobie. Każde dwa z nich oznaczają, że koszt nicnierobienia już narasta — utrzymanie systemu legacy kosztuje zwykle 2–3 razy więcej niż jego nowoczesny odpowiednik, jeszcze przed doliczeniem ryzyka bezpieczeństwa i zgodności. Modernizacja opłaca się, gdy koszt nicnierobienia przewyższa koszt pracy; dla systemów takich jak w tym case study ten punkt minęliśmy dawno. Pierwszy krok jest zawsze ten sam i zawsze tani względem problemu: audyt kodu, który daje listę blokerów, mapę ryzyk i plan etapowy z wyceną. Typowe skale: mały projekt (kilkanaście tysięcy linii) modernizuje się w dni do tygodni; średni system z frameworkiem i integracjami — 2–8 tygodni; duże systemy bez testów — etapami przez kilka miesięcy. Jeśli rozpoznajesz swój system w tym case study, zacznij od audytu — wszystko dalej to decyzje podejmowane z danymi w ręku.

Wnioski

Trzy wnioski z tego projektu, w kolejności ważności. Po pierwsze: testy przed refaktoryzacją, zawsze — testy charakterystyczne to różnica między modernizacją a hazardem i najtańsze ubezpieczenie całego programu. Po drugie: moduł po module bije wielką rewolucję — każdy moduł wdrażał się i stabilizował osobno, system nigdy nie stanął, a biznes widział postęp od pierwszego miesiąca zamiast czekać rok na przepisanie. Po trzecie: monitoring od pierwszego dnia — warstwa obserwowalności zwróciła się w pierwszym miesiącu i to ona czyni pozostałe dwa wnioski weryfikowalnymi na produkcji, a nie na tablicy.

Najczęściej zadawane pytania