Wstęp
Znasz to uczucie, gdy wchodzisz do piwnicy pełnej starych mebli i myślisz „kiedyś to się przyda”? W backendzie mamy podobnie – kod, który napisaliśmy rok temu, endpoint, którego nikt nie wywołuje, biblioteka dołączona na wszelki wypadek. To wszystko ma swoją cenę. Nie chodzi tylko o dług techniczny w sensie moralnym, ale o realne pieniądze – czas serwerów, koszty chmury, opóźnienia w deploymencie, a nawet ryzyko bezpieczeństwa.
Jako praktyk, który widział backendy od małych startupów po średnie e-commerce, powiem Ci wprost: martwy kod to cichy zabójca budżetu IT. W tym artykule pokażę trzy konkretne przypadki z mojej praktyki, które kosztowały firmy dziesiątki tysięcy złotych – i jak je wyeliminować.
Lekcja 1: Nieużywane endpointy API – płacisz za coś, czego nie używasz
Przypadek
Klient – sklep e-commerce z około 50 000 produktów. Aplikacja backendowa w Node.js, która ewoluowała przez 3 lata. Podczas audytu znaleźliśmy 15 endpointów API, które nie były wywoływane od ponad 6 miesięcy. Pozornie – nic strasznego. Ale każdy z nich był podpięty do bazy danych, logował zdarzenia, wysyłał eventy do kolejki. Serwer i tak musiał utrzymywać połączenia, alokować pamięć.
Skutek
Miesięczny koszt utrzymania tych endpointów (obliczony na podstawie czasu CPU, pamięci i transferu) wynosił około 1200 zł. Rocznie – ponad 14 000 zł. Do tego dochodził czas dewelopera przy każdym deploymencie – musieli testować, czy coś się nie zepsuło, choć nikt tego nie używał.
Co zrobić?
- Monitoruj użycie endpointów – narzędzia jak New Relic czy Datadog pokażą, które ścieżki są martwe.
- Wprowadź politykę wygaszania – po 3 miesiącach bez użycia oznacz endpoint jako deprecated, po 6 – usuń.
- Automatyzuj czyszczenie – skrypt CI/CD, który raportuje nieużywane trasy.
Lekcja 2: Legacy zależności – niewidzialna pułapka na twoje pieniądze
Przypadek
Firma SaaS B2B z monolitem w Pythonie. W repozytorium znajdowało się 47 bibliotek zewnętrznych, z czego 12 nie było używanych w żadnym imporcie. Brzmi niewinnie? Problem w tym, że każda biblioteka to potencjalne luki bezpieczeństwa, konieczność aktualizacji przy zmianie wersji języka, a także wydłużony czas budowania obrazu Docker.
Skutek
Usunięcie tych 12 bibliotek skróciło czas builda z 12 do 8 minut. Brzmi mało, ale przy 20 deployach dziennie daje to 80 minut oszczędności czasu processora CI/CD. W przeliczeniu na koszty – około 300 zł miesięcznie na samych zasobach CI. Do tego ryzyko: jedna z bibliotek miała krytyczną lukę CVE, która została załatana dopiero po naszej interwencji.
Co zrobić?
- Używaj narzędzi do analizy zależności – np.
pip freezez porównaniem do faktycznych importów (Python),depcheck(Node),dependency-check(Java). - Regularnie przeglądaj requirements.txt / package.json – usuwaj to, czego nie ma w kodzie.
- Wprowadź zasadę „zero martwych zależności” – przy każdym code review sprawdzaj, czy nowa biblioteka jest faktycznie używana.
Lekcja 3: Martwe funkcje i endpointy wewnętrzne – koszt utrzymania wiedzy
Przypadek
System CRM dla średniej firmy. Odkryliśmy funkcję calculateDiscountV2, która została napisana dwa lata temu, ale nigdy nie wdrożona – zastąpiona przez V3. Kod wciąż był w repozytorium, testy jednostkowe dla V2 działały, a w konfiguracji pozostał legacy flag.
Skutek
Każdy nowy programista spędzał średnio 2 godziny na zrozumieniu, po co istnieje ta funkcja, dlaczego nie jest używana i czy można ją usunąć. Przy rotacji 3 deweloperów rocznie – 6 godzin straconego czasu. Do tego testy – 15 testów dla martwego kodu wydłużało czas suity testowej o 30 sekund. Przez rok to łącznie około 3 godzin czasu CI. Niby drobnostki, ale w sumie – koszt utrzymania wiedzy i uwagi.
Co zrobić?
- Usuwaj martwy kod, nie komentuj – komentarze to zło, usuwaj nieużywane funkcje w całości.
- Używaj feature flags z terminem ważności – jeśli flag nie jest używany przez 3 miesiące, automatycznie go usuń.
- Regularnie czyść repozytorium – co kwartał przeglądaj kod pod kątem nieużywanych importów, funkcji, klas.
Podsumowanie
Martwy kod to nie tylko kwestia estetyki – to realne pieniądze. W trzech opisanych przypadkach firmy traciły od kilku do kilkudziesięciu tysięcy złotych rocznie na utrzymaniu czegoś, czego nikt nie używa. Do tego dochodzi ryzyko bezpieczeństwa, wolniejsze buildy, wyższe koszty chmury i frustracja zespołu.
Z mojego doświadczenia wynika, że audyt backendu pod kątem martwego kodu to jedna z najszybciej zwracających się inwestycji. Wystarczy jeden dzień pracy senior developera, by wyczyścić 80% bezużytecznego balastu. Efekt? Niższe rachunki, szybsze deploye, mniej błędów.
Jeśli czujesz, że Twój backend może mieć podobne problemy, warto przyjrzeć się bliżej. Często to, czego nie widać, kosztuje najwięcej.
