Audyt kodu legacy to punkt wyjścia każdej modernizacji — techniczny przegląd systemu, który odpowiada na pytania, co działa, co jest ryzykiem i od czego zacząć. Dobry audyt nie kończy się raportem na półce, lecz listą priorytetów z roadmapą. Ten artykuł rozkłada audyt na części: co obejmuje, jak przebiega, ile trwa, ile kosztuje i jak czytać jego wyniki.
Najważniejsze: Audyt kodu legacy obejmuje pięć obszarów — architekturę i zależności, bezpieczeństwo, wydajność, testy i dług techniczny. U mnie audyt techniczny to 2 000 zł netto jednorazowo, a jego efektem jest raport z priorytetami i roadmapą modernizacji. Audyt bez rekomendacji „co dalej" jest tylko kosztem, nie inwestycją.
Kiedy zamówić audyt kodu legacy
Audyt ma sens w kilku konkretnych sytuacjach
- przejmujesz projekt po poprzednim wykonawcy i chcesz wiedzieć, co dostajesz,
- system działa, ale każda zmiana zajmuje tygodnie i boisz się wdrożeń,
- dostałeś wycenę „przepiszemy od zera" i chcesz drugą opinię przed decyzją,
- planujesz rozwój produktu i potrzebujesz wiedzieć, czy obecny kod to udźwignie,
- chcesz sprzedać lub kupić firmę i potrzebujesz due diligence technicznego.
Wspólny mianownik tych sytuacji jest jeden: podejmujesz decyzję o dużych pieniądzach i chcesz ją oprzeć na stanie faktycznym, a nie na opiniach. Audyt jest właśnie po to — żeby decyzja o modernizacji, przepisaniu albo zostawieniu systemu w spokoju była decyzją świadomą.
Co obejmuje audyt — pięć obszarów
Kompleksowy audyt kodu legacy patrzy na system z pięciu stron. Każda odpowiada na inne ryzyko biznesowe.
Architektura i zależności. Jak system jest zbudowany, gdzie są granice modułów, jak przepływa między nimi ruch i dane. Mapa zależności pokazuje, które moduły można modernizować niezależnie, a które są tak splecione, że każda zmiana grozi awarią. W tym obszarze wychodzi też na jaw, czy architektura da się uratować, czy trzeba wydzielać i przepisywać pojedyncze fragmenty. Szersze tło tego etapu opisuję w pillarze o modernizacji legacy code.
Bezpieczeństwo. Przestarzałe biblioteki ze znanymi podatnościami, nieaktualna wersja PHP i frameworka, błędy w obsłudze danych wejściowych, zarządzanie dostępami i sekretami. Punktem odniesienia jest OWASP Top 10 — lista najczęstszych klas podatności aplikacji webowych. W starych systemach PHP typowo znajduję dwie kategorie problemów: biblioteki, których nikt nie aktualizował od lat, oraz kod sprzed ery frameworków, pisany bez myślenia o injection i XSS. Jeśli system jest w Laravel, szczegóły rozkładam w artykule o bezpieczeństwie aplikacji Laravel.
Wydajność. Gdzie system spędza czas, które zapytania do bazy są najdroższe, które fragmenty kodu spowalniają użytkownika. Audyt wydajności odpowiada też na pytanie, czy problem leży w kodzie, czy w infrastrukturze — a to dwie różne naprawy i dwa różne budżety.
Testy i jakość. Czy istnieją jakiekolwiek testy, co pokrywają, jak wygląda proces wdrożenia. W starych projektach odpowiedź brzmi zwykle „testów nie ma, a wdrożenie robi się ręcznie przez FTP". To nie wyrok — to punkt startowy, od którego planujemy testy charakterystyczne i CI/CD.
Dług techniczny. Skala i rozmieszczenie długu — ile kosztuje utrzymanie obecnego stanu i co się stanie, jeśli nic nie zrobimy. Metody pomiaru i sposób myślenia o spłacie długu opisuję w artykule o długu technologicznym.
Jak przebiega audyt w praktyce
Audyt kodu legacy to nie jednorazowe czytanie plików. To kilkudniowy proces w kilku krokach
- Rozmowa o biznesie — które funkcje generują przychód, co planujecie rozwijać, gdzie dziś boli najbardziej. Audyt techniczny bez kontekstu biznesowego ocenia kod, a nie ryzyko.
- Inwentaryzacja — struktura projektu, zależności, wersje PHP i bibliotek, historia zmian, stan środowiska (serwery, kopie zapasowe, monitoring).
- Analiza statyczna — PHPStan, Psalm i narzędzia do wykrywania martwego kodu i duplikacji. Automaty znajdują to, co człowiekowi zajęłoby tygodnie.
- Analiza bezpieczeństwa — zestawienie bibliotek z bazami podatności, przegląd kodu pod kątem OWASP Top 10, przegląd zarządzania dostępami.
- Analiza wydajności — profilowanie najważniejszych ścieżek, wolne zapytania, wąskie gardła.
- Raport i roadmapa — lista znalezisk z oceną ryzyka, rekomendacje i kolejność działań z szacunkami.
Kluczowy jest punkt szósty. Raport bez roadmapy to wyliczanka problemów, która paraliżuje zamiast pomagać. Dobry audyt kończy się odpowiedzią w stylu: „w tym kwartale zabezpieczamy płatności i łatamy biblioteki, w następnym refaktoryzujemy moduł rozliczeń, przepisanie modułu raportów odkładamy na później". Decyzja o tym, czego nie robimy, jest równie ważna jak lista tego, co robimy.
Ile trwa i ile kosztuje audyt
Audyt techniczny małego i średniego systemu to zwykle od 3 do 10 dni roboczych, zależnie od rozmiaru kodu i dostępności dokumentacji. Dla większych systemów proces dzieli się na etapy — najpierw przegląd zgrubny, potem pogłębienie w obszarach o najwyższym ryzyku.
W mojej praktyce audyt techniczny to 2 000 zł netto jednorazowo. To kwota, która zwraca się na kilka sposobów: pozwala uniknąć przepisywania systemu, którego nie trzeba przepisywać, porządkuje kolejność prac (a więc wydatki), a w przypadku zakupu firmy lub projektu — bywa, że ratuje przed zakupem problemu wartego dziesiątki tysięcy złotych. Widełki całego programu modernizacji rozkładam w artykule o kosztach modernizacji legacy, a usługę audytu i modernizacji opisuję na stronie modernizacji legacy PHP.
Jak czytać raport z audytu
Raport z dobrego audytu ma trzy warstwy, które czyta się w tej kolejności
- ryzyka krytyczne — rzeczy, które mogą kosztować najwięcej i wymagają decyzji natychmiast: dziury bezpieczeństwa, brak kopii zapasowych, pojedyncze punkty awarii,
- priorytety modernizacji — moduły do refaktoryzacji w kolejności według stosunku ryzyka do kosztu,
- rekomendacje strategiczne — odpowiedź na pytanie „refaktoryzować, przepisywać, czy zostawić", z uzasadnieniem i widełkami kosztów.
Czerwona flaga przy odbiorze raportu: dokument, który wylicza wyłącznie problemy i kończy wnioskiem „trzeba wszystko przepisać". Rzetelny audyt pokazuje też, co w systemie jest zdrowe i co warto zachować — w starych systemach zwykle jest tego więcej, niż się wydaje na pierwszy rzut oka.
Co dalej po audycie
Audyt domyka etap rozpoznania i otwiera plan działania. Najczęstsza sekwencja po audycie wygląda tak: łatamy krytyczne dziury bezpieczeństwa, pokrywamy testami najważniejsze ścieżki, refaktoryzujemy moduły według priorytetów i uruchamiamy CI/CD. Cały proces — krok po kroku — opisuję w przewodniku o modernizacji legacy code.
Jeśli szukasz wsparcia w audycie swojego systemu, napisz do mnie — zaczynamy od rozmowy o tym, co system robi dla biznesu, a kończymy roadmapą, którą możesz zrealizować ze mną albo we własnym zespole.
Najczęściej zadawane pytania
Co dokładnie dostaję w raporcie z audytu?
Raport z listą znalezisk w pięciu obszarach (architektura, bezpieczeństwo, wydajność, testy, dług techniczny), oceną ryzyka dla każdego znaleziska, roadmapą modernizacji z kolejnością i szacunkami oraz rekomendacją strategiczną — refaktoryzować, przepisywać czy zostawić bez zmian.
Czy audyt wymaga dostępu do produkcji?
Nie do danych produkcyjnych. Do audytu wystarczy dostęp do repozytorium kodu, konfiguracji środowiska (bez sekretów produkcyjnych) i — opcjonalnie — możliwość uruchomienia systemu na kopii. Dane klientów nie są potrzebne do oceny jakości kodu.
Czy audyt zrobi mi konkurencja, skoro udostępniam kod?
Audyt to usługa zaufania i warto go zamówić u wykonawcy, z którym ewentualnie chcesz pracować dalej — nie musisz, ale to naturalne. Jeśli obawiasz się o kod, zabezpiecz to umową NDA i zakresem dostępu (repozytorium bez sekretów, środowisko testowe). Standardem jest też zapis, że raport i wiedza o kodzie nie mogą być wykorzystane poza audytem.
Czy audyt może się zakończyć rekomendacją „nic nie robić"?
Tak i zdarza się to częściej, niż można by sądzić. Jeśli system jest stabilny, bezpieczny w granicach rozsądku i rzadko się zmienia, uczciwa rekomendacja brzmi: zostawić, pilnować aktualizacji bezpieczeństwa i wrócić do tematu, gdy pojawi się realna potrzeba biznesowa. Audyt, który zawsze kończy się dużym projektem, nie jest audytem.