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. Takie ratowanie nie jest efektowne, ale daje satysfakcję — i ma powtarzalny schemat.
Tydzień 1: czytać, nie pisać
Przez pięć dni roboczych niczego nie scalamy do main. 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 dokument audytowy. Co działa, co zepsute, co ryzykowne, czego brakuje. Dzielimy się nim 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 w ogóle nie startuje — naprawiamy to w pierwszej kolejności. Jeśli startuje, ale pęka pod obciążeniem — dodajemy load-test. Pod koniec drugiego tygodnia merge'e znów są bezpieczne.
Tygodnie 3–N: wypuszczanie backlogu
Teraz działamy w naszym zwykłym rytmie Run: 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 na skończenie projektu to zwykle po prostu skończyć projekt.