Koszty ukryte w martwych zależnościach: 3 lekcje z backendu
Każdy, kto choć raz deploymentował aplikację produkcyjną, zna ten stan – wszystko działa, testy przechodzą, a Ty myślisz o kolejnym featurze. Tymczasem w repozytorium rośnie tykająca bomba: martwe zależności. Nieużywane biblioteki, stare paczki, fragmenty kodu, które kiedyś miały sens, a dziś tylko wiszą. Brzmi znajomo? W JurskiTech.pl widzimy to regularnie podczas audytów backendów naszych klientów. Dziś pokażę Ci trzy konkretne przypadki, które kosztowały firmy realne pieniądze – i jak ich uniknąć.
Lekcja 1: Niepotrzebny ciężar
Wyobraź sobie aplikację e-commerce z 2018 roku. Do obsługi koszyka użyto biblioteki „shopping-cart-js”, która w tamtym czasie była standardem. Dziś nikt już jej nie aktualizuje, a Twój kod woła ją do paru miejsc. Problem? Każdy npm install ciągnie całe drzewo zależności tej paczki. Przy 50 takich nieużywanych pakietach, czas budowania rośnie z 2 do 10 minut. Koszt? Programista czeka, płacisz za jego czas, a deploye są rzadsze. Raz u jednego klienta zliczyliśmy – 30 minut dziennie * 200 dni = 100 godzin rocznie. Przy stawce 100 zł/h to 10 000 zł rocznie za powietrze.
Co robić? Regularne audyty zależności. Narzędzia jak npm-check czy depcheck pokażą, co jest nieużywane. Wdrożenie procesu: przed dodaniem nowej paczki – pytanie, czy da się bez niej.
Lekcja 2: Dziura w zabezpieczeniach
To była zimna rozmowa z klientem z branży medycznej. Ich aplikacja do rezerwacji wizyt używała biblioteki „connect” z wersji 2.x. Działało, nikt nie ruszał. Aż do audytu bezpieczeństwa – okazało się, że „connect” 2.x ma znaną lukę pozwalającą na atak XSS. Aktualizacja? Prosta, ale przez lata nikt tego nie zrobił. Efekt? Firma musiała przeprowadzić awaryjny patch w weekend, a koszt utraty zaufania pacjentów – bezcenny. Martwe zależności to nie tylko ciężar, ale też otwarte drzwi dla ataków.
Co robić? Skonfiguruj automatyczne skanowanie SCA (Software Composition Analysis). Narzędzia takie jak Snyk, Dependabot (GitHub) czy OWASP Dependency Check robią robotę za Ciebie. Alerty o przestarzałych paczkach powinny być traktowane jak błędy krytyczne.
Lekcja 3: Syndrom „działa, nie ruszaj”
Backendowy monolit pisany w 2015 roku. Framework Rails 4.2, gem „devise” do autoryzacji, ale rok temu przenieśli logowanie na własne rozwiązanie. Kod z devise został? Tak. I nikt nie wiedział, że konfiguracja devise wciąż jest ładowana, a stare endpointy wiszą na ślepo. Raz na miesiąc aplikacja dziwnie się restartowała – nikt nie wiedział dlaczego. Po trzech miesiącach debugowania okazało się, że devise starał się połączyć do nieistniejącej bazy Redis. Martwy kod potrafi generować realne błędy.
Co robić? Testowanie kodu pod kątem dead code – narzędzia IDE (np. WebStorm) pokazują nieużywane importy. Wprowadź zasadę: przy każdej zmianie usuń też niepotrzebne fragmenty. Regularne refaktoryzacje to oszczędność, nie fanaberia.
Jak zacząć?
Zamiast wielkiego projektu, zrób mały krok. W najbliższym sprincie dodaj zadanie: „Usuń martwe zależności z głównego repozytorium”. Użyj narzędzi do analizy. Zobaczysz, ile wiszącego balastu wywieziesz. W JurskiTech.pl tak zaczynamy audyty backendów – od szybkich wygranych, które dają oddech zespołowi i poprawiają bezpieczeństwo.
Podsumowanie
Martwe zależności to nie tylko kwestia porządku w kodzie – to realne koszty: opóźnienia, luki, niepotrzebne bugi. Traktuj swój kod jak ogród – regularnie pielęgnuj i usuwaj chwasty. Twoja firma (i Twój zespół) Ci za to podziękują.
Chcesz sprawdzić, czy Twój backend nie skrywa tykającej bomby? Skontaktuj się z nami – w JurskiTech.pl pomagamy firmom oczyścić kod i odzyskać kontrolę.
