Jak ratujemy niedokończone bazy kodu bez przepisywania od zera
Około 40% naszej pracy to przejmowanie projektów, które zaczęły inne zespoły. Oto dokładny playbook, którego trzymamy się w pierwsze dwa tygodnie.
„Poprzedni zespół zniknął na trzy tygodnie przed premierą" to jedno z najczęstszych zdań, jakie słyszymy na pierwszej rozmowie. Ratunki nie są glamour, ale są wdzięczne — i mają powtarzalny kształt.
Tydzień 1: czytać, nie pisać
Nic nie wlewamy do main przez pięć dni roboczych. Czytamy. Każdy plik, każdą migrację, każdy commit-message. Uruchamiamy npx depcheck, sprawdzamy bundle size, otwieramy konsolę Firebase, listujemy każdy zewnętrzny serwis, robimy snapshot każdej zmiennej env.
Wynik: 5-stronicowy audyt-dokument. Co działa, co zepsute, co ryzykowne, czego brakuje. Dzielimy z klientem na rozmowie, nie w mailu.
Tydzień 2: stabilizacja mainline
- CI uruchamia się na każdym PR.
- Typecheck przechodzi.
- Preview-deploye na każdym PR.
- Error tracking (Sentry) łapie prod-błędy.
- Krytyczne ścieżki dostają Playwright smoke-testy.
Jeśli aplikacja nawet nie startuje — to fixujemy pierwsze. Jeśli startuje, ale pęka na skali — dodajemy load-test. Pod koniec drugiego tygodnia merge'e znów są bezpieczne.
Tygodnie 3–N: wypuszczanie backlogu
Teraz idziemy zwykłym Run-rytmem: tygodniowy release, review przez preview, pętla feedbacku przez analitykę. Klienci, którzy przychodzą w panice, zwykle osiągają spokojną przewidywalność do 4. tygodnia.
Czego NIE robimy
Nie przepisujemy dla samego przepisywania. Nie zmieniamy frameworków. Nie „modernizujemy" kodu, który nie sprawia problemu. Najszybszy sposób skończyć projekt to zwykle skończyć projekt.