Czym jest dług techniczny (technical debt) w projektach IT?

Dług techniczny – to jak kredyt, który bierzesz, aby przyspieszyć rozwój produktu programowego, ale potem odsetki zaczynają się kumulować w postaci zwiększonego czasu i kosztów na utrzymanie oraz rozwój funkcjonalności. Pojęcie to zostało wprowadzone przez Howarda Cunninghama w celu opisania sytuacji, w których programiści podczas intensywnej pracy ignorują długoterminową czystość kodu w imię krótkoterminowych celów.

Czysty kod – marzenie każdego programisty, ale w praktyce okoliczności często zmuszają do kompromisów. Presja ze strony biznesu, terminy i ograniczony budżet mogą zmusić do wydania funkcjonalności przed tym, jak kod zostanie dopracowany do doskonałości. Tymczasowe rozwiązania stopniowo przekształcają się w "brudny kod (code smell)", który utrudnia dalszą pracę.

Jedną z najważniejszych przyczyn, dla których kod przekształca się z czystego w brudny, jest brak dokumentacji i zautomatyzowanych testów. Dokumentacja pomaga nowym członkom zespołu szybciej zrozumieć projekt, a zautomatyzowane testy pozwalają utrzymać kod w stabilnym stanie, zapobiegając nieoczekiwanym błędom przy zmianach.

Rozwój monolitycznych projektów, gdzie zmiany w jednym miejscu mogą niespodziewanie wpływać na inne części systemu, również stanowi dużą przeszkodę dla czystego kodu. Ograniczenia komponentów i duża liczba zależności tworzą sytuację, w której refaktoryzacja staje się nie tylko pożądana, ale wręcz konieczna. Jednak jeśli refaktoryzację odkłada się, z czasem koszty z nią związane wzrosną wykładniczo, ponieważ zależny kod nadal się kumuluje.

Do innych przyczyn powstawania i narastania długu technicznego można zaliczyć brak wyraźnej interakcji między członkami zespołu, co prowadzi do "sałatki" z różnych stylów kodu, oraz brak ujednoliconych standardów jego pisania. Poniżej znajduje się lista powszechnych przyczyn długu technicznego.

Dług techniczny nie tylko spowalnia rozwój, ale także zwiększa ryzyko błędów i obniża ogólną jakość produktu programowego. Podobnie jak dług finansowy, jego spłata wymaga czasu, zasobów i odważnych decyzji ze strony kierownictwa dla długoterminowego zdrowia projektu i zespołu.

Istnieją terminy (deadliny) dla realizacji funkcjonalności sklepu internetowego. Zespół programistów postanawia szybko wdrożyć system zarządzania zamówieniami. Na początku zdecydowali się użyć prostej struktury bazy danych, w której wszystkie dane o zamówieniach, w tym szczegóły produktów, informacje o klientach i transakcjach, są przechowywane w jednej tabeli. To rozwiązanie pozwala szybko uruchomić projekty (MVP), ale w miarę wzrostu liczby zamówień i złożoności danych, taka struktura staje się nieefektywna.

Z czasem, gdy objętości danych rosną, zapytania do bazy danych stają się wolne i mniej efektywne, co prowadzi do wydłużenia czasu przetwarzania zamówień i obniżenia ogólnej wydajności strony. Dodatkowo, trudno jest przeprowadzać analizy danych i zapewniać niezbędne raporty bez refaktoryzacji struktury bazy danych.

Rozwiązanie tego problemu wymaga znacznych wysiłków w zakresie refaktoryzacji bazy danych, w tym przemyślenia tabel, optymalizacji zapytań oraz ewentualnego wdrożenia nowych technologii cache'owania. Taka refaktoryzacja zajmie czas i zasoby, które mogłyby być wykorzystane na rozwój innych aspektów projektu, ale bez tego kroku dalszy wzrost i efektywność sklepu internetowego będą ograniczone. I tutaj rozumiemy, czym jest 'dług'. Niezbędną refaktoryzację można oszacować w czasie i pieniądzach (wynagrodzenie zespołu). Nie poświęcając tego czasu/pieniędzy od samego początku, 'zaciągnęliśmy' dług wobec siebie, odkładając pracę nad bardziej złożonym systemem na później. Jednak czasami dług techniczny jest uzasadniony - robimy MVP i uruchamiamy projekt, aby zacząć zarabiać. I dopiero potem możemy refinansować uzyskane środki w kodzie.

Ta lista nie jest pełna, ale koncepcyjnie myślę, że można zrozumieć istotę.

Presja ze strony biznesu (potrzeba rozpoczęcia sprzedaży): Często projekty są uruchamiane zanim będą w pełni gotowe. Decyzja o szybkim uruchomieniu może stworzyć problemy, które będą wymagały czasu na refaktoryzację i naprawę ewentualnych błędów. Nie jest wykluczone, że błędy mogą wpłynąć na pierwsze wrażenie potencjalnych klientów i wpłynąć na sprzedaż.

Brak zrozumienia wpływu kumulacji długu technicznego: Właściciele biznesu mogą nie dostrzegać skutków ignorowania długu technicznego, uważając go za mniej ważny niż bezpośrednie wprowadzenie produktu na rynek. Czasami dość trudno jest wyjaśnić osobie bez wiedzy o procesach IT, dlaczego należy wydawać pieniądze i czas na przepisywanie/pisanie kodu. Świadomość przychodzi dopiero wtedy, gdy dług techniczny zaczyna wpływać na biznes.

Monolityczna architektura: Brak modułowości w projektowaniu systemu ogranicza elastyczność i wymaga dużych wysiłków przy jakichkolwiek zmianach czy udoskonaleniach, co spowalnia adaptację do zmieniających się wymagań biznesowych.

Brak testów: Brak kompleksowych testów zwiększa ryzyko błędów, co może prowadzić do poważnych awarii w przyszłości.

Brak dokumentacji: Jeśli projekt rozwija się bez odpowiedniego dokumentowania, nowi członkowie zespołu spędzą więcej czasu na naukę systemu, co obniża ich wydajność. Ponadto nowi programiści będą odciągać starych pytaniami. Możliwe, że podczas przeglądu kodu będzie więcej zapytań o poprawki kodu (od programistów, którzy znają niuanse kodu, architektury, procesów biznesowych itp.).

Zła interakcja/komunikacja: Kiedy wiedza i doświadczenie nie są rozpowszechniane w organizacji, efektywność pracy spada. T

Równoległy rozwój w kilku gałęziach: Równoległe programowanie w kilku gałęziach tworzy trudności przy scalaniu kodu, kumulując dług techniczny, który należy spłacić przed uruchomieniem.

Odkładanie refaktoryzacji: Zwłoka w optymalizacji kodu tworzy sytuację, w której kod staje się coraz bardziej niewygodny do utrzymania i rozwijania.

Niedotrzymywanie standardów: Ignorowanie ustalonych standardów i konwencji może utrudnić przyszłą integrację i wsparcie projektu.

Brak kompetencji: Kiedy programiści nie mają wystarczających umiejętności do pisania czystego, efektywnego kodu, może to prowadzić do stworzenia problematycznego produktu.

Rozwój przez wykonawców: Produkty programowe opracowane przez wykonawców, a następnie zintegrowane w projekcie, często wymagają dodatkowych kosztów na ich adaptację i optymalizację.

Złe kierownictwo: Nieskuteczne kierownictwo może zwiększać dług techniczny poprzez niewystarczająco przemyślane procesy.

Zmiany specyfikacji w ostatniej chwili: Te zmiany mogą uruchamiać łańcuch niezbędnych adaptacji w projekcie bez wystarczającego czasu na ich wdrożenie (optymalizację, testowanie itp.).

Zakres Creep: Nieprzewidywalne zmniejszenie lub odkładanie zakresu prac może stworzyć dodatkową presję i zwiększyć dług techniczny poprzez nieplanowane zmiany w projekcie.