Każde przejęcie cudzego kodu jest inne. Różne technologie, różne style pisania, różny poziom dokumentacji (od obszernej – co jest rzadkością – do zupełnie żadnej). Ale niezależnie od tego, z czym trafiamy, nasz proces wygląda podobnie.

Dzień 1: Uruchomienie i orientacja

Zanim zaczniemy cokolwiek analizować, chcemy zobaczyć działający system – lokalnie lub na środowisku testowym. To pierwsze zderzenie z rzeczywistością.

Pytania, które zadajemy sobie w pierwszym dniu:

  • Czy da się uruchomić projekt w oparciu o README (jeśli istnieje)?
  • Ile czasu zajmuje konfiguracja środowiska? (to dobry wskaźnik jakości projektu)
  • Jakie jest pierwsze wrażenie po wejściu do kodu?
  • Czy historia gitowa jest czytelna, czy to jeden commit „initial" sprzed 4 lat?
Czas uruchomienia projektu od zera to jeden z najlepszych wskaźników stanu kodu. Projekt, który zajmuje 5 minut – jest dobrze utrzymany. Projekt, który zajmuje 2 dni – ma problem.

Tydzień 1: Audyt i mapa systemu

Naszym celem w pierwszym tygodniu jest stworzenie mapy systemu – rozumienie tego, co istnieje, bez modyfikowania czegokolwiek.

Co mapujemy?

  • Architektura – jak system jest zorganizowany, jakie są główne moduły i ich odpowiedzialności
  • Przepływ danych – skąd dane wchodzą, jak są przetwarzane, gdzie trafiają
  • Zależności zewnętrzne – API, bazy danych, zewnętrzne serwisy, biblioteki
  • Punkty krytyczne – miejsca, których modyfikacja jest najbardziej ryzykowna
  • Długi technologiczne – hardkodowane wartości, brak obsługi błędów, podatności bezpieczeństwa

Nie piszemy jeszcze kodu. Czytamy, pytamy, notujemy.

Tydzień 2: Pierwsze działania stabilizacyjne

Dopiero gdy mamy ogólny obraz, zaczynamy działać. Pierwsze kroki są zawsze stabilizacyjne:

  • Weryfikacja i aktualizacja backupów – czy działają? jak często są robione?
  • Zamknięcie krytycznych luk bezpieczeństwa
  • Konfiguracja monitoringu i alertów (jeśli brakuje)
  • Ujednolicenie zmiennych środowiskowych – wyrzucenie hardkodowanych haseł i kluczy
  • Tworzenie środowiska testowego (jeśli nie istnieje)
  • Napisanie podstawowej dokumentacji uruchomieniowej

Żadna z tych zmian nie dotyka logiki biznesowej. Każda zwiększa bezpieczeństwo i obniża ryzyko.

Zasady, których się trzymamy przy cudzym kodzie

Zasada 1: Nie oceniaj – rozumiej

Poprzedni programista podejmował decyzje w konkretnym kontekście – z ograniczeniami czasu, budżetu i wiedzy, którą miał wtedy. Zamiast pytać „kto to napisał?", pytamy „dlaczego tak to napisano?" – często odkrywamy interesującą historię.

Zasada 2: Małe, bezpieczne kroki

Pierwsze zmiany w nowym projekcie są zawsze małe i izolowane. Jeden plik, jeden moduł, jedna funkcja. Każda zmiana jest testowana zanim pójdzie dalej.

Zasada 3: Dokumentuj to, czego się uczysz

Każde odkrycie ląduje w dokumentacji – choćby w plikach README lub komentarzach w kodzie. Za miesiąc możemy nie pamiętać, dlaczego dana funkcja działa właśnie tak.

Zasada 4: Nie naprawiaj tego, co działa

Refaktoryzacja dla samej refaktoryzacji to strata czasu i ryzyko. Naprawiamy to, co generuje realne problemy – błędy, wąskie gardła, luki bezpieczeństwa. Reszta może poczekać.

Potrzebujesz kogoś, kto przejmie Twój projekt i nim się zaopiekuje? Robimy to regularnie – bez rewolucji, bez przepisywania od zera.

Porozmawiajmy →

Czego się spodziewamy, biorąc cudzy kod

Po kilku latach przejmowania różnych projektów mamy realistyczne oczekiwania:

  • Brak dokumentacji – norma, nie wyjątek. Dokumentacja jest jednym z pierwszych priorytetów.
  • Mieszane podejście do stylu kodu – różni programiści, różne konwencje w jednym projekcie. Da się z tym żyć.
  • Kilka niespodzianek – ukryte zależności, nieoczywiste konfiguracje, „magiczne liczby" bez komentarza. To część przygody.
  • Miejsca, które „zawsze działają i nikt nie wie dlaczego" – traktujemy je z szacunkiem i dotykamy ostrożnie.

Podsumowanie

Przejmowanie starego kodu to praca wymagająca cierpliwości, pokory i systematyczności. Nie ma skrótów. Ale zrobione metodycznie – jest przewidywalne i bezpieczne.

  • Najpierw uruchom i zrozum – zanim cokolwiek zmienisz
  • Mapuj system zanim go modyfikujesz
  • Pierwsze działania to zawsze stabilizacja, nie refaktoryzacja
  • Dokumentuj każde odkrycie
  • Nie oceniaj poprzedniego programisty – zrozum jego kontekst