Odejście programisty to jeden z tych momentów, w których firmy uświadamiają sobie, jak bardzo były uzależnione od jednej osoby. System działa, ale nikt poza autorem nie wiedział, jak go uruchomić, gdzie leżą pliki, jakie są hasła do bazy danych, ani co się stanie, gdy cokolwiek pójdzie nie tak.

Przejęcie projektu po poprzednim deweloperze nie musi być katastrofą – ale wymaga metodycznego podejścia. W tym artykule opisujemy, co robimy, gdy bierzemy na siebie cudzy kod.

Krok 1: Zabezpiecz dostępy i środowisko

Zanim dotkniesz kodu, upewnij się, że masz dostęp do wszystkiego, czego potrzebujesz – i że tylko właściwe osoby mają dostęp do systemu produkcyjnego.

  • Repozytorium kodu – GitHub, GitLab, Bitbucket lub własny serwer. Upewnij się, że masz własne konto z dostępem i że poprzedni programista został usunięty lub zmieniono uprawnienia.
  • Serwer i hosting – SSH, FTP, panel hostingowy, dostęp do AWS/GCP/Azure. Jeśli poprzedni deweloper miał swoje klucze SSH, należy je unieważnić.
  • Baza danych – dane logowania, kopie zapasowe, lokalizacja bazy. Wykonaj natychmiastowy backup, zanim cokolwiek zmienisz.
  • Zmienne środowiskowe i sekrety – klucze API, hasła, tokeny. Jeśli leżą w kodzie (często tak jest), to priorytet do naprawy.
  • Domeny i certyfikaty SSL – kto zarządza domeną, kiedy wygasa certyfikat, czy są ustawione auto-odnawianie.
Zanim zaczniemy pisać jakikolwiek kod, robimy backup. Zawsze. Bez wyjątków. Zdarzało się, że poprzedni deweloper "czyścił" środowisko przy odejściu.

Krok 2: Zrób inwentaryzację tego, co masz

Przed jakimkolwiek działaniem warto wiedzieć, z czym mamy do czynienia. To nie jest etap naprawiania – to etap rozumienia.

Jakie pytania zadajemy na tym etapie?

  • W jakiej technologii jest napisany system? (język, framework, wersja)
  • Ile kodu jest w repozytorium? Czy istnieje historia commitów?
  • Czy są jakiekolwiek testy automatyczne?
  • Jakie zewnętrzne serwisy i integracje są używane? (płatności, emaile, API)
  • Gdzie i jak jest wdrożony system? (serwer VPS, cloud, shared hosting?)
  • Czy jest środowisko testowe / staging, czy tylko produkcja?
  • Czy gdzieś jest jakakolwiek dokumentacja – choćby plik README?

Odpowiedzi na te pytania dają nam obraz skali problemu. Czasem jest lepiej niż się wydaje. Czasem gorzej.

Krok 3: Audyt kodu i infrastruktury

To jest clue całego procesu. Audyt nie polega na ocenianiu jakości kodu poprzedniego programisty – polega na zrozumieniu, co system robi, jak to robi i gdzie są ryzyka.

Na co patrzymy podczas audytu?

  • Architektura – czy system jest monolitem, mikroserwisami, czy czymś pomiędzy? Jak podzielony jest kod?
  • Zależności i biblioteki – czy są aktualne? Czy są biblioteki z krytycznymi podatnościami bezpieczeństwa?
  • Bezpieczeństwo – czy hasła są zahardkodowane? Czy są walidacje danych wejściowych? Czy połączenia z bazą są bezpieczne?
  • Wydajność – czy są oczywiste wąskie gardła? Zapytania do bazy w pętlach, brak indeksów, brak cache?
  • Obsługa błędów – co się dzieje, gdy coś pójdzie nie tak? Czy błędy są logowane?
  • Konfiguracja – czy różne środowiska (dev/prod) są oddzielone? Czy klucze API są trzymane w bezpieczny sposób?

Przejmujesz projekt po poprzednim deweloperze i nie wiesz, od czego zacząć? Robimy audyty kodu i przejmujemy projekty IT bez rewolucji.

Porozmawiajmy →

Krok 4: Zidentyfikuj ryzyka krytyczne

Po audycie masz listę problemów. Nie wszystkie są równie ważne. Zanim zaczniesz naprawiać, podziel je na kategorie:

  • Krytyczne (napraw natychmiast) – podatności bezpieczeństwa, brak backupów, wygasające certyfikaty, zahardkodowane hasła do bazy danych
  • Ważne (napraw w ciągu tygodnia) – przestarzałe biblioteki ze znane podatnościami, brak środowiska testowego, brak monitorowania
  • Do poprawy (planowo) – jakość kodu, brak dokumentacji, dług technologiczny, brak testów
  • Informacyjne (wiedzieć, nie panikować) – "brzydki" kod, nieoptymalne rozwiązania, które działają i nie stwarzają ryzyka

Priorytetyzacja ratuje przed tym, żeby zacząć refaktorować kod, który działa, zamiast zamknąć lukę bezpieczeństwa, przez którą ktoś mógłby wykraść dane klientów.

Krok 5: Stwórz minimalną dokumentację

Nawet jeśli nie masz czasu na pełną dokumentację, minimum to:

  • README z instrukcją uruchomienia systemu lokalnie
  • Diagram architektury (nawet narysowany ręcznie)
  • Lista wszystkich zewnętrznych zależności i integracji
  • Procedura wdrożenia na produkcję krok po kroku
  • Lokalizacja i dostęp do wszystkich kluczowych zasobów (serwer, baza, repozytoria)
  • Kontakty – hostingodawca, zewnętrzne API, właściciel domeny

Ta dokumentacja nie jest dla nowego programisty. Jest dla Ciebie – na wypadek, gdyby o 3 w nocy coś przestało działać i trzeba byłoby szybko cokolwiek sprawdzić.

Krok 6: Zaplanuj pierwsze małe zmiany

Pierwsze zmiany w przejętym projekcie powinny być celowo małe i odwracalne. To nie jest moment na wielkie refaktoryzacje i przepisywanie modułów.

Zamiast tego:

  • Zamknij krytyczne luki bezpieczeństwa zidentyfikowane w audycie
  • Dodaj monitoring i alerty (gdy system padnie, chcesz wiedzieć przed klientem)
  • Skonfiguruj automatyczne backupy
  • Dodaj środowisko testowe, jeśli nie istnieje

Każda z tych zmian jest niezależna i bezpieczna. Budujesz siatkę bezpieczeństwa, zanim zaczniesz eksperymentować z kodem.

Typowe pułapki przy przejmowaniu projektu

Pułapka 1: „Przepiszemy to od nowa"

To najczęstszy odruch po zobaczeniu trudnego kodu. Rzadko dobry pomysł – szczególnie jako pierwsza decyzja. System, który chcesz przepisać, zawiera lata rozwiązanych problemów biznesowych, często nieudokumentowanych. Przepisując, ryzykujesz utratę tej wiedzy. Najpierw zrozum, potem decyduj.

Pułapka 2: Brak testów przed zmianami

Nawet jeśli nie ma testów automatycznych, przed każdą zmianą w produckji warto ręcznie sprawdzić kluczowe scenariusze. Lista "co sprawdzić po wdrożeniu" ratuje przed nieprzyjemnymi niespodziankami.

Pułapka 3: Optymizm co do harmonogramu

Przejęcie cudzego projektu zawsze trwa dłużej niż się wydaje. Stary kod skrywa niespodzianki. Zaplanuj bufor czasowy – i nie obiecuj klientowi ani pracodawcy konkretnych terminów zanim nie zrobisz audytu.

Podsumowanie: Przejęcie projektu to maraton, nie sprint

Przejąć projekt to jedno. Zrozumieć go w takim stopniu, żeby móc go bezpiecznie rozwijać – to zupełnie inne zadanie, które trwa tygodnie lub miesiące.

Kluczowe zasady, które nam pomagają:

  • Najpierw zabezpiecz, potem zrozum, na końcu zmieniaj
  • Małe, odwracalne kroki – szczególnie na początku
  • Dokumentuj to, czego się uczysz – nawet pobieżnie
  • Nie oceniaj poprzedniego programisty – on rozwiązywał inne problemy w innych warunkach
  • Backupy, backupy, backupy

Jeśli właśnie stoisz przed przejęciem cudzego projektu i nie wiesz od czego zacząć – napisz do nas. Robimy to regularnie.