Dług technologiczny (ang. technical debt) to - w dużym uproszczeniu - pojęcie odnoszące się do kompromisów, które są podejmowane podczas tworzenia oprogramowania w celu szybszego dostarczenia produktu lub funkcji kosztem jakości kodu. Może obejmować tymczasowe obejścia, skróty i techniczne kompromisy, które później mogą wymagać dodatkowego nakładu pracy na poprawki i optymalizacje.
Dług technologiczny pojawia się często w wyniku decyzji oszczędnościowych, które mogą prowadzić do długoterminowych konsekwencji finansowych.
Przyczyny powstawania długu technologicznego:
Presja czasu: konieczność szybkiego dostarczenia produktu na rynek.
Niedobór zasobów: ograniczona liczba programistów lub ograniczony budżet.
Zmiany w wymaganiach: dynamicznie zmieniające się wymagania projektowe.
Niedostateczna dokumentacja: brak odpowiedniej dokumentacji technicznej i projektowej.
Konsekwencje długu technologicznego:
Wzrost kosztów utrzymania: zwiększona pracochłonność przy wprowadzaniu zmian i poprawek.
Obniżona wydajność: zmniejszenie wydajności systemu z powodu nieoptymalnego kodu.
Trudności w skalowaniu: problemy z rozwojem i skalowaniem systemu w przyszłości.
Niższa jakość produktu: potencjalne błędy i awarie systemu.
Spadek konkurencyjności: firma pracująca na systemie z długiem technologicznym jest na gorzej pozycji rynkowej w stosunku do tej, która takiego nie ma.
Kto jest dłużnikiem, a kto wierzycielem w długu technologicznym?
Dług w klasycznym rozumieniu jest wtedy, gdy dłużnik ma zobowiązanie u wierzyciela. Aby to wyjaśnić posłużmy się przykładem:
Adam, która ma oprogramowanie w swojej firmie, wymyślił nową funkcjonalność w module faktur. Poprosił o wycenę swojego programistę - Karola.
Karol stwierdził, że zadanie będzie wymagało przeróbki części systemu i zajmie mu to tydzień pracy. Jest, co prawda, opcja aby zrobić to szybciej – w jeden dzień, ale będzie to rozwiązanie tymczasowe, nieoptymalnie (nie będzie działać szybko), obciąży bazę danych oraz będzie praktycznie nie do rozszerzenia o kolejne funkcjonalności.
Adam stwierdził, że bardzo zależy mu na czasie i wizja posiadania nowej funkcjonalności już jutro skłoniła go do podjęcia decyzji o wybraniu “tańszego” (celowo w cudzysłowie) rozwiązania.
Adam, świadomie lub nie, właśnie zaciągnął dług technologiczny. Odpowiadając zatem na pytanie postawione wcześniej - dłużnikiem jest Adam, a wierzycielem - aplikacja. Adam, wybierając rozwiązanie tymczasowe, zaciągnął dług, który będzie musiał spłacić w przyszłości z odsetkami.
Mówiąc wprost:
W przyszłości takie samo zadanie będzie trwało dłużej czyli po pierwsze - będzie to więcej kosztowało, a po drugie - tempo wdrażania nowych funkcjonalności będzie dużo mniejsze.
Jak sprawdzić czy mój produkt ma dług technologiczny?
Kiedy wiadomo, że powstaje dług technologiczny?
1. Przestarzały, nieestetyczny wygląd
Aplikacja jest niespójna wizualnie - te same elementy (np. przyciski) na każdym ekranie wyglądają inaczej (mają inny rozmiar, marginesy, kolory) lub zachowują się inaczej np. sortowanie w tabeli na jednym ekranie obsługujemy, klikając na nazwę kolumny, a na kolejnym – wybierając wartości z listy.
2. Wolne działanie, spadek wydajności i brak nowych funkcji
Brak nowych funkcji negatywnie wpływa na całościowy rozwój systemu. Każda zmiana powoduje, że system musi być testowany “od nowa”, można dzięki temu wykryć błędy (tzw. bugi). Wybieranie rozwiązań “tymczasowych”, nie do końca przemyślanych, może spowodować spowolnienie systemu.
Przestarzałe rozwiązania i zduplikowane funkcje mogą zwiększać ryzyko wystąpienia błędów, co negatywnie wpływa na wydajność aplikacji i doświadczenie użytkownika. Nieoptymalne zapytania do bazy danych lub niepotrzebne obliczenia to tylko wierzchołek góry lodowej.
Często takie rozwiązania są wymuszane pod presją czasu, a wraz z rozwojem systemu powodują stopniowe spowolnienie systemu.
3. Zmiana prostej rzeczy zajmuje dużo czasu
Wynika to z tego, że w systemie z długiem technologicznym, rozwiązania są pisane tak, aby działały dla końcowego użytkownika, a nie koniecznie tak, aby je w łatwy sposób rozszerzać, czyli dodawać nowe funkcje.
Czasem z pozoru prosta rzecz może być bardzo czasochłonna, właśnie przez kod napisany “na szybko”. To jest właśnie etap spłacania długu technologicznego (z odsetkami!).
4. Coraz częściej słyszysz “nie da się tego zrobić”
Oczywiście są rzeczy których faktycznie nie da się zrobić, ale… w dużej części przypadków nie da się tego zrobić ze względu na skomplikowanie i zawiłość kodu.
5. Nikt nie chce pracować przy Twoim projekcie
I tutaj chodzi zarówno o programistów w Twojej firmie jak i podwykonawców.
Są technologie, które powodują, że u niektórym włosy stają dęba. Programiści nie chcą dotykać kodu, grzebanie w przestarzałej technologii jest dla nich nieatrakcyjne.
W wielu przypadkach proponowanym rozwiązaniem jest.. przepisanie systemu w innej technologii.
6. Coraz mniej rzeczy w systemie dzieje się automatycznie
Wraz z rozwojem systemu (i często zaciąganiem długu technicznego) komunikacja pomiędzy modułami może być trudniejsza do zrealizowania lub w skrajnych przypadkach - niemożliwa.
Wówczas ta odpowiedzialność przenoszona jest na użytkownika:
wiele rzeczy odbywa się na zasadzie import – export,
użytkownik musi robić to samo dwa razy na różnych ekranach,
proste procesy biznesowe stają się skomplikowane do “wyklikania”.
7. System nie jest testowany
Mam na myśli tutaj zarówno testerów manualnych, którzy fizycznie klikają po aplikacji w celu znalezieniu błędów, jak i testy zaprogramowane, które uruchamiają się automatycznie przy każdym wdrożeniu.
Jak zarządzać długiem technologicznym?
Jeśli już wiesz, że Twój system czy aplikacja ma przestarzałe rozwiązania, luki bezpieczeństwa, potrzebuje nowych funkcjonalności, ponieważ koszty utrzymania stały się zbyt wysokie, warto opracować plan, który pomoże w zarządzaniu długiem technologicznym.
Brak aktualizacji oprogramowania i audytu infrastruktury może prowadzić do wystąpienia luk bezpieczeństwa, które sprzyjają włamaniom i atakom hakerskim.
Możesz zwrócić się w tym celu do firm IT, które zajmują się wsparciem w tym zakresie lub - jeśli nie możesz sobie na to pozwolić - spróbować opracować taki plan wraz ze swoim działem IT.
1. Identyfikacja i ocena długu technologicznego
Przeglądy kodu: regularne przeglądy kodu, które pozwalają zidentyfikować obszary wymagające poprawy.
Narzędzia analizy statycznej: korzystanie z narzędzi do analizy statycznej kodu, które pomagają wykrywać techniczne zobowiązania i potencjalne problemy.
Dokumentacja długu: tworzenie i utrzymywanie dokumentacji technicznej dotyczącej zidentyfikowanego długu technologicznego.
2. Priorytetyzacja zadań związanych z długiem technologicznym
Ocena ryzyka: określenie, które elementy długu technologicznego mają największy wpływ na stabilność, wydajność i skalowalność systemu.
Planowanie: włączenie zadań związanych z redukcją długu technologicznego do harmonogramu sprintów i planów projektowych.
3. Refaktoryzacja kodu
Regularna refaktoryzacja: regularne przeglądy i refaktoryzacja kodu w celu poprawy jego struktury i jakości bez zmiany zewnętrznego zachowania.
Refaktoryzacja krok po kroku: stopniowe wprowadzanie zmian, aby nie zakłócać bieżącej pracy nad projektem.
4. Automatyzacja testów
Testy jednostkowe: tworzenie i utrzymywanie testów jednostkowych, które pozwalają na szybkie wykrywanie błędów.
Testy integracyjne: implementacja testów integracyjnych, które sprawdzają poprawność współdziałania różnych komponentów systemu.
Ciągła integracja: wdrożenie praktyk ciągłej integracji (CI), które automatyzują procesy testowania i wdrażania kodu.
5. Edukacja i kultura zespołu
Szkolenia: regularne szkolenia dla programistów dotyczące najlepszych praktyk programistycznych i zarządzania długiem technologicznym.
Kultura jakości: promowanie kultury zespołu, która ceni jakość kodu i długoterminowe myślenie nad krótkoterminowymi korzyściami.
6. Transparentność i komunikacja
Raportowanie: regularne raportowanie stanu długu technologicznego do interesariuszy i zespołu zarządzającego.
Transparentność: utrzymywanie transparentności w zakresie decyzji technicznych i ich wpływu na projekt.
7. Planowanie i strategia
Długoterminowa strategia: tworzenie długoterminowej strategii zarządzania długiem technologicznym, która obejmuje regularne oceny i aktualizacje planów działania.
Wbudowany czas na techniczne zadania: włączenie w planowanie projektu zadań technicznych związanych z redukcją długu technologicznego.
8. Regularne przeglądy i aktualizacje
Oceny techniczne: regularne oceny techniczne systemu w celu identyfikacji nowego długu technologicznego i monitorowania postępów w redukcji istniejącego długu.
Adaptacja i aktualizacja: aktualizacja strategii i planów działania w oparciu o wyniki przeglądów i zmieniające się potrzeby projektu.
Prawidłowe zarządzanie długiem technologicznym zapewnia dalszy rozwój systemu i - co za tym idzie- firmy, ale wymaga to ciągłej uwagi i zaangażowania całego zespołu. Kluczowe jest utrzymanie równowagi między bieżącymi wymaganiami biznesowymi a długoterminowymi celami technicznymi, aby zapewnić zdrowy rozwój i utrzymanie systemu.
Podsumowanie
Wyżej wymienione punkty nie napawają optymizmem. ale zastanówmy się: czy dług technologiczny jest faktycznie taki zły, jak go malują?
Otóż życie nie jest zero-jedynkowe i można podzielić dług na dobry i zły - analogicznie do długu finansowego. Nie można powiedzieć że kredyt hipoteczny rozsądnie zaciągnięty jest złym długiem, ale chwilówka na “zachcianki” - już tak.
Dobry dług technologiczny jest świadomie zaciągnięty i - przede wszystkim -spłacony na czas, bo jeśli nie będziemy o nim myśleć, to w dłuższej perspektywie może narobić nam sporo kłopotów.
Comments