15.06.20224 min

Justyna SzatanRedakcja Bulldogjob

Mity o długu technicznym

Kwestia długu technicznego jest podnoszona na tyle często, że narosło wokół niego sporo mitów i nieporozumień. Przyjmy się tej kwestii bliżej.

Mity o długu technicznym

Pojęcie długu technologicznego towarzyszy nam od 1992 r. za sprawą Warda Cunninghama, który nazwał korelację pomiędzy krótkoterminowymi rozwiązaniami systemów technicznych i konsekwencjami, które znacznie wpływają na pracę nad kodem.

To zbiór licznych mniejszych problemów (zazwyczaj nie do zauważenia dla końcowego użytkownika), które nagromadzone utrudniają ustalanie priorytetów, wprowadzanie zmian i rozwijanie produktu.

W tym artykule znajdziesz najpopularniejsze mity, które dotyczą długu technologicznego, a także zderzenie ich z rzeczywistością.


Pogromcy mitów

Przechodzimy do konkretów, bo w Bulldogjob staramy się przekazać Ci samo mięsko, a moje ulubione ziemniaczki w postaci ciekawostek znajdziesz na końcu artykułu. Przygotuj popcorn, usiądź wygodnie i baw się dobrze!


1. Wszystko zależy od jakości kodu i zależności

To żadne rocket science — łatki, które robi się na szybko mają duży potencjał, by utrudnić ulepszanie kodu. I to jest fakt, jeśli nie poprzedza tego rozwiązania żadna analiza i rozsądne planowanie to prawdopodobnie w niedalekiej przyszłości trzeba będzie to odkręcać.

W rzeczywistości wystarczy dobierać dobrą infrastrukturę do projektu i tworzyć spójną architekturę na zasadzie kompletnych klocków, które potem można ułożyć w inny sposób. Z tym się wiąże też 2 mit.


2. Najnowsze technologie najlepszą ochroną

Niektórzy powtarzają jak mantrę, że najnowsze frameworki uchronią Cię niczym talizman od złego długu technologicznego.

Ponownie wiele zależy od infrastruktury — zazwyczaj działasz na kilku systemach i najnowsze frameworki niekoniecznie muszą być z nimi kompatybilne. Na to potrzeba czasu. Wręcz takie wymuszanie zmian może wręcz potęgować dług technologiczny.


3. To zło wcielone, którego trzeba się wystrzegać

To mój ulubiony. Oczywiście, że profilaktyka jak analizowanie dostępnych rozwiązań, refaktoryzacja czy testy regresywne są niezbędne, dla utrzymania dobrej jakości kodu i minimalizowania efektu długu technologicznego.

Ale paniczne wystrzeganie się go ponownie może przynieść odwrotny efekt, ponieważ nie zawsze czas na to pozwoli lub moce przerobowe, a klient będzie nieugięty. Co wtedy? Pójdzie szybki fix, który do Was z czasem i tak wróci.

Na szczęście to nie koniec świata. Można długiem racjonalnie zarządzać i nawet wykorzystać jako cenne narzędzie. Jeśli to dobrze rozegracie zespół, nauczy się współpracować, stanie się bardziej elastyczny i raczej nie będziecie popełniać tych samych błędów następnym razem.


4. Dług szkodzi tylko programistom

To bardzo życzeniowe podejście. Owszem — to oni ślęczą nad kodem i nieraz muszą go ponownie przepisywać w wielu miejscach, co jest czasochłonne. Natomiast nagromadzony dług przekłada się w praktyce na całą firmę.

Devowie się wkurzają, bo mają obsuwę. Ich lidera ciśnie obsługa klienta pushowana przez niezadowolonego klienta itd. Właśnie dlatego tak ważne jest monitorowanie długu, by informować wszystkich na bieżąco o postępach prac.


5. Dług jest amofriczny

Każdy dług technologiczny wyobraża sobie inaczej, a w praktyce jego poziom skomplikowania i dokuczliwość jest zależna od masy czynników jak aktualność bibliotek, duplikacja funkcjonalności, niechlujny i zagmatwany kod, czy, co gorsza, niewystarczająco pokryty niezbędnymi testami.

Na podstawie, chociażby powyższych przykładów możesz ustalić ile pracy, czasu i kosztów będzie wymagało zmniejszenie długu technologicznego i ułożenie z niego planu.


6. Przepisanie kodu to jedyna opcja

Brzmi jak sytuacja bez wyjścia, która zapewne ściąga sen z powiek developerom, który kiedykolwiek to spotkało. Takie rozwiązanie wiąże się ze znacznym ryzykiem niepowodzenia, licznymi opóźnieniami, które ponownie przełożą się na koszty.

Lepszą praktyką jest bieżąca analiza sytuacji i naprawianie np. co kwartał konkretnych modułów. Skrupulatne prowadzenie dokumentacji, przygotowywanie planów działania i etapowe naprawianie powinno pomóc zmniejszyć dług technologiczny i jednocześnie nie zamykać sobie drogi do dalszego rozwoju.


Podsumowanie

Spisałam tylko kilka najpopularniejszych mitów o długu technologicznych, ale to dopiero szczyt góry lodowej. Wiesz już, że nie ma powodów do obaw i wbrew pozorom może czasem pomóc. 

Pamiętaj, by trzymać rękę na pulsie i nie załamywać się w pozornie przegranych sytuacjach. Stwórz z zespołem spis największych problemów jakie macie, a następnie wspólnie przegadajcie, jak i kiedy to naprawić.

Podpowiedzi, w jaki sposób wykorzystać dług technologiczny na swoją korzyść znajdziesz w tym artykule Dość narzekania na dług techniczny.


Bonus

Według badania przeprowadzonego przez naukowców z norweskiej politechniki w Oslo w 2018 r. na grupie 226 specjalistów IT z różnych szczebli kariery, aż 73% respondentów nie śledzi na bieżąco długu technologicznego i nie planuje etapów naprawy.

Okazało się, że 27% badanych stara się zmniejszyć potencjalny dług technologiczny na etapie pisania kodu, co wydłuża jego czas realizacji. 

Co ciekawe respondenci badania stwierdzili, że nanoszenie poprawek, a nawet średnie redukowanie długu technologicznego w trakcie pracy nad projektem wydłuża proces realizacji o około 33% czasu. W niektórych firmach dubluje to koszty lub wymaga znacznie większych zasobów ludzkich.

Jednakże samodzielnie musisz ocenić, czy na podstawie powyższych danych długu technologicznego należy się bać, czy lepiej go oswoić i nauczyć pracować według pewnych schematów.

<p>Loading...</p>