Na początku mojej kariery jako świeżo upieczona menedżerka produktu, kiedy po raz pierwszy usłyszałam o długu technicznym (inaczej długu technologicznym), nie byłam do końca pewna, co to oznacza. Co zabawne, myślałam, że chodzi o pożyczkę, którą zaciągnęliśmy na zakup oprogramowania firm trzecich, i przez dwa lub trzy tygodnie z pełnym przekonaniem niewłaściwie używałam tego terminu. Wyobraźcie sobie moje zażenowanie, kiedy po spotkaniu zespołu inżynierowie wzięli mnie na bok, żeby delikatnie mnie poprawić!

Dlatego, aby oszczędzić nam wszystkim rumieńców w pracy i pomóc nam zyskać uznanie w oczach naszych inżynierów, przyjrzyjmy się temu, czym jest dług techniczny i dlaczego my, jako menedżerowie produktu, powinniśmy się nim interesować.

Czym jest dług techniczny i kiedy staje się problemem?

Tworzenie oprogramowania polega na równoważeniu zakresu funkcjonalności produktu z wysoką jakością kodu. Po drodze czasami korzystamy ze skrótów, aby przyspieszyć proces tworzenia — te skróty nazywamy długiem technicznym lub długiem technologicznym.

Kiedy zaciągnięcie długu technicznego jest dobrym pomysłem, a kiedy staje się tykającą bombą? Aby odpowiedzieć na to pytanie, najpierw przyjrzymy się historii długu technologicznego.

Czym jest dług techniczny?

Ward Cunningham, twórca tego terminu, porównuje dług techniczny do długu finansowego — zaciąganie zobowiązań kosztem przyszłego tempa prac i stabilności jest dopuszczalne, ale ostatecznie musimy spłacić ten dług. To pojęcie, które powinien rozumieć każdy zespół programistyczny i które każdy menedżer produktu powinien brać pod uwagę przy podejmowaniu decyzji dotyczących produktu.

Dług technologiczny pomaga nam wydawać produkty przed terminem i szybciej przekazywać je klientom. Jednak w końcu musimy „spłacić dług”, inwestując w jakość naszego kodu.

Najlepiej byłoby, gdybyśmy świadomie decydowali, czy chcemy korzystać z długu technicznego, czy go unikać. Podobnie jak w przypadku długu finansowego, nie chcemy później zostać zaskoczeni nieprzewidzianym kosztem!

Uproszczona definicja długu technicznego

Dług techniczny (w niektórych zespołach nazywany również długiem kodu) oznacza przewidywany koszt przyszłych przeróbek, który powstaje, gdy wybieramy krótkoterminowy skrót zamiast lepszego rozwiązania wymagającego więcej czasu. To jak płacenie odsetek od pożyczki — koszt długu technicznego rośnie z czasem.

Jedną z analogii, których używam, jest golenie brody. Jeśli się spieszę i szybko się ogolę, prawdopodobnie nie będzie to najbardziej dokładne golenie w życiu i będę musiała później wrócić, aby je poprawić.

Czas i wysiłek potrzebne na oba golenia — pierwsze oraz drugie, poprawiające — będą łącznie większe, niż gdybym od razu ogoliła się dokładnie.

Czasami jednak, gdy zaczyna nam brakować czasu, musimy zdecydować się na szybkie golenie!

Porównanie długu finansowego z długiem technicznym

Aby lepiej zobrazować tę koncepcję, przyjrzyjmy się bliżej porównaniu długu finansowego i technicznego. W końcu menedżerowie produktu muszą rozumieć zarówno pojęcia związane z finansami przedsiębiorstwa, jak i techniczne koncepcje programistyczne!

Zalety długu finansowego: Dług finansowy umożliwia wykorzystanie dźwigni finansowej. Pożyczenie pieniędzy może zapewnić kapitał potrzebny do inwestowania w możliwości rozwoju. Ponadto dług finansowy pozwala natychmiast uzyskać dostęp do zasobów lub aktywów bez konieczności dokonywania płatności z góry.

Wady długu finansowego: Dług finansowy wiąże się z wieloma różnymi rodzajami kosztów. Odsetki od długu finansowego mogą z czasem narastać, zmniejszając ogólną rentowność. Ponadto niewłaściwe zarządzanie długiem finansowym może prowadzić do niestabilności finansowej.

Co więcej, dług może ograniczać elastyczność finansową i uniemożliwiać nam podążanie określonymi ścieżkami w przyszłości. Niewywiązywanie się ze zobowiązań finansowych może również zaszkodzić reputacji organizacji.

Zalety długu technicznego: Dług techniczny umożliwia szybsze początkowe tworzenie produktu, pomagając dotrzymać napiętych terminów lub wykorzystać możliwości rynkowe. Ponadto, podobnie jak dźwignia finansowa, zaciągnięcie długu technicznego może zmniejszyć początkowe koszty tworzenia.

Wady długu technicznego: Podobnie jak odsetki narastają w przypadku długu finansowego, dług techniczny kumuluje się, gdy na istniejących skrótach budowane są kolejne funkcje lub zmiany, przez co przyszłe prace stają się bardziej złożone i kosztowne. Ponadto dług techniczny często prowadzi do nieoptymalnej jakości kodu, co z czasem skutkuje wyższymi kosztami utrzymania.

Dług techniczny może ograniczać zdolność produktu do dostosowywania się do zmieniających się warunków rynkowych lub uwzględniania nowych funkcji. Nierozwiązany dług techniczny może prowadzić do awarii systemu, luk w zabezpieczeniach lub problemów z wydajnością, wpływając na możliwość dalszego funkcjonowania produktu.

Co to dla nas oznacza? Cóż, zarówno w przypadku długu finansowego, jak i technicznego celem nie jest całkowite unikanie długu. Kluczowe jest natomiast rozważne zarządzanie.

Choć pewien poziom długu może być strategicznym narzędziem rozwoju, musimy uważnie go monitorować i nim zarządzać, aby zminimalizować długoterminowe negatywne konsekwencje.

Przykłady długu technicznego

W świecie inżynierii oprogramowania zespoły programistyczne regularnie spotykają się z długiem technicznym. Omówmy kilka najczęstszych przykładów.

Starszy kod

Niektóre zespoły mogą korzystać z przestarzałego kodu starszego typu, aby szybko wdrożyć funkcję. Może to zapewnić natychmiastową funkcjonalność, ale później może wymagać znacznego refaktoryzowania, zwłaszcza w miarę dodawania nowych funkcji. Podobnie jak starożytny rękopis, kod starszego typu był przekazywany przez kolejne pokolenia programistów, gromadząc na sobie ciężar historii.

Choć w czasach swojej świetności mógł doskonale spełniać swoje zadanie, upływ czasu stopniowo osłabia jego elastyczność i łatwość utrzymania. Awarie i błędy w środowisku produkcyjnym mają tendencję do pojawiania się, gdy zbytnio polegamy na kodzie starszego typu!

Kodowanie na sztywno

Kodowanie na sztywno odnosi się do praktyki umieszczania konkretnych wartości lub stałych bezpośrednio w kodzie zamiast korzystania z konfigurowalnych ustawień.

Choć takie podejście może w krótkiej perspektywie przyspieszyć proces tworzenia, często prowadzi do komplikacji w przyszłości. Wyobraźmy sobie sytuację, w której zakodowana na sztywno wartość, taka jak ścieżka pliku lub próg limitu czasu, musi zostać zmieniona w całej rozbudowanej bazie kodu. Może to szybko przerodzić się w czasochłonne i podatne na błędy zadanie, zagrażając łatwości utrzymania i elastyczności oprogramowania.

Aby uniknąć tego problemu, programiści powinni wybierać opcje konfigurowalne, zwiększając elastyczność swojego kodu.

Duplikowanie kodu

Duplikowanie kodu występuje, gdy podobne lub identyczne fragmenty kodu pojawiają się w wielu miejscach projektu. Początkowo może wydawać się wygodnym skrótem, pozwalającym zaoszczędzić czas podczas tworzenia. Jednak wraz z rozwojem oprogramowania i zmianą wymagań utrzymanie spójności oraz wprowadzanie aktualizacji stają się skomplikowanym przedsięwzięciem.

Duplikowanie kodu nie tylko zwiększa ryzyko wprowadzenia błędów, ale także zwielokrotnia wysiłek potrzebny do przyszłego rozszerzania funkcji i usuwania błędów. Dążenie do ponownego wykorzystania kodu oraz eliminowanie zbędnego kodu to podstawowe zasady przeciwdziałania temu problemowi.

Brak dokumentacji

Dokumentacja pełni funkcję nici przewodniej, która oświetla drogę obecnym i przyszłym programistom. Brak wyczerpującej dokumentacji przypomina wyruszenie w złożoną podróż bez mapy. Może zacząć się od braku komentarzy w kodzie wyjaśniających uzasadnienie określonych decyzji dotyczących kodu, a skończyć na braku podręczników użytkownika i dokumentacji architektury systemu.

Choć początkowa faza tworzenia może przebiegać sprawnie, długoterminowe konsekwencje mogą być poważne. Debugowanie staje się zagadkowym przedsięwzięciem, przekazywanie wiedzy między członkami zespołu jest trudne, a skalowanie projektu często przypomina poruszanie się po labiryncie w ciemności. Dbałość o wyczerpującą dokumentację jest światłem wskazującym drogę naprzód w tworzeniu oprogramowania.

Brak testów automatycznych

Brak testów automatycznych przypomina żeglowanie łodzią bez wcześniejszego sprawdzenia, czy nie ma przecieków. Testy automatyczne (w tym testy jednostkowe, integracyjne i regresji) są czujnymi strażnikami jakości i stabilności kodu.

Gdy się z nich rezygnuje, konsekwencje mogą nie być od razu widoczne. Początkowo tworzenie może postępować szybko, a oprogramowanie może wydawać się funkcjonalne. Jednak wraz z rozrostem i ewolucją bazy kodu zaczynają pojawiać się nieprzewidziane problemy. Błędy regresji, w przypadku których wcześniej działające funkcje przestają działać po wprowadzeniu nowych zmian, stają się codziennością.

Bez testów automatycznych zapewniających siatkę bezpieczeństwa zespół programistyczny musi polegać na testach ręcznych, które są czasochłonnym i podatnym na błędy procesem. Wprowadzenie testów automatycznych od samego początku zapewnia utrzymanie właściwego kursu na wzburzonym morzu tworzenia oprogramowania.

Jaka jest rola długu technicznego w podejściu Agile?

Ach, zwinne tworzenie oprogramowania! Metodyki Scrum i zasady zawarte w Manifeście Agile opierają się na zmianie i szybkości. Ale gdzie w tym wszystkim mieści się dług techniczny? W końcu dług techniczny nie jest bezpośrednio omawiany w dokumentach założycielskich Agile.

Cóż, posłużmy się analogią z Gwiezdnych wojen — Sokół Millennium był nieustannie konserwowany przez Hana Solo i Chewbaccę, aby pozostawać w najlepszym stanie podczas ich wypraw. Podobnie zwinny zespół produktowy zarządza długiem technicznym, aby utrzymać jakość oprogramowania i umożliwiać swoim klientom bohaterskie przygody! 

Jak wykorzystywać dług techniczny i nim zarządzać

W zespołach Agile istnieje świadomość, że czasami trzeba zaciągnąć pewien dług techniczny, aby szybko zaspokoić potrzeby biznesowe. Pamiętajmy, że zaciąganie takiego długu nie zawsze jest czymś złym. Martin Fowler, autorytet w dziedzinie zwinnego tworzenia oprogramowania, zauważa, że chodzi tu o kompromisy. Można zaakceptować pewien dług na wczesnym etapie cyklu życia produktu programistycznego, aby zweryfikować koncepcję lub szybciej wejść na rynek.

Kluczowe znaczenie ma zarządzanie długiem technicznym. Dług techniczny powinien być udokumentowany w rejestrze zadań, ustalony pod względem priorytetów i uwzględniony w przyszłych sprintach. Aby było to możliwe, menedżerowie produktu muszą opierać się na solidnym zarządzaniu projektami i dobrze rozumieć, jaką ilość długu technicznego zaciągnięto do tej pory.

Kiedy dług techniczny stanowi problem?

Gdy interesariusze nie zdają sobie sprawy z długu technicznego lub gdy proces tworzenia oprogramowania w dużej mierze opiera się na obejściach, właśnie wtedy powinny rozbrzmieć dzwonki alarmowe. Dlaczego?

1. Jest niewidoczny: Bez wskaźników lub regularnych przeglądów kodu mogą pojawić się ukryte luki.
2. Wpływa na doświadczenia użytkownika: Jeśli problemy leżące u podstaw systemu zaczną wpływać na jego funkcjonalność, nie jest to już tylko problem programisty, lecz problem biznesowy.
3. Utrudnia dodawanie nowych funkcji: Programiści uwikłani w zły kod są mniej produktywni, a ich kreatywność spada.
4. Nie ma go na mapie drogowej: Zespoły powinny być świadome długu technicznego i mieć strategię radzenia sobie z nim. Nie wahaj się korzystać z zewnętrznych webinarów i zasobów, aby opracować plan działania.

Jak mierzyć dług techniczny

Korzystając z narzędzi, takich jak praktyki DevOps i automatyzacja, zespoły mogą monitorować bazę kodu i śledzić narastający dotychczas dług techniczny. Poniżej zebrałem dwanaście różnych sposobów monitorowania długu technicznego.

Nie musisz korzystać ze wszystkich! Potraktuj tę listę jako punkt wyjścia. Wybierz jeden lub dwa sposoby do wdrożenia w ciągu najbliższego miesiąca, a następnie stopniowo rozwijaj w zespole umiejętność śledzenia i rozwiązywania długu technicznego.

1) Statyczna analiza kodu: Narzędzia takie jak SonarQube, ESLint czy FindBugs mogą automatycznie analizować kod pod kątem różnych problemów, takich jak złożoność kodu, oznaki złej jakości kodu i potencjalne błędy. Dostarczają ilościowych wskaźników jakości kodu i długu technicznego na podstawie zdefiniowanych wcześniej reguł i progów.

2) Pokrycie kodu: Możemy ocenić, jaka część bazy kodu jest objęta automatycznymi testami, mierząc pokrycie kodu za pomocą narzędzi takich jak JaCoCo czy Istanbul. Niskie pokrycie kodu może wskazywać na brak testów i potencjalny dług techniczny.

3) Wzajemne przeglądy kodu: Przeprowadzanie wzajemnych przeglądów kodu pozwala programistom identyfikować i omawiać potencjalne elementy długu technicznego. Poza tym dwie głowy są lepsze niż jedna — to świetny sposób na unikanie złych wzorców kodu! Zespoły mogą korzystać z list kontrolnych lub wytycznych do oceny jakości kodu i dokumentowania zidentyfikowanych problemów. Liczba i dotkliwość problemów wykrytych podczas przeglądów może służyć jako jakościowa miara długu technicznego.

4) Ręczne inspekcje kodu: Programiści i zespoły mogą przeprowadzać ręczne inspekcje kodu lub przeglądy, aby identyfikować obszary bazy kodu, które mogą skorzystać z refaktoryzacji. Proces ten często obejmuje przeglądanie kodu przez doświadczonych programistów i dokumentowanie problemów, ponieważ zazwyczaj najlepiej wyczuwają oni dług techniczny związany z projektem. 

5) Rejestr długu technicznego: Prowadzenie rejestru produktu lub listy zidentyfikowanych elementów długu technicznego jest powszechną praktyką. Każdy element rejestru powinien zawierać opis, ocenę wpływu i priorytet. Rozmiar i priorytet elementów w rejestrze dostarczają jakościowej miary długu technicznego.

6) Śledzenie błędów i problemów: Analiza procesu priorytetyzacji błędów może ujawnić częstotliwość i dotkliwość problemów związanych z długiem technicznym. Duża liczba zgłoszeń błędów lub częste powracanie tych samych problemów może wskazywać na ukryty dług techniczny.

7) Szacowanie i punkty historyjek: Podczas planowania nowych prac lub historyjek użytkownika zespoły programistyczne mogą oszacować nakład pracy wymagany do rozwiązania elementów długu technicznego. To szacowanie nakładu pracy, często wyrażane w postaci punktów historyjek w metodykach Agile, określa ilościowo pracę potrzebną do rozwiązania długu technicznego.

8) Wskaźniki złożoności kodu: Wskaźniki takie jak złożoność cyklomatyczna, liczba wierszy kodu i zmienność kodu mogą dostarczyć informacji o złożoności i łatwości utrzymania bazy kodu. Większa złożoność i nadmierne zmiany w określonych obszarach kodu mogą wskazywać na dług techniczny.

9) Opinie użytkowników: Opinie użytkowników i prośby o pomoc mogą pośrednio wskazywać na dług techniczny. Częste skargi użytkowników dotyczące wydajności systemu, niezawodności lub nieoczekiwanego działania mogą sygnalizować ukryte problemy, które wymagają rozwiązania.

10) Wskaźniki automatyzacji testów: Monitorowanie wskaźników związanych z automatyzacją testów, takich jak czas wykonywania testów, odsetek nieudanych testów i niestabilne testy, może pomóc ocenić kondycję infrastruktury testowej i zidentyfikować obszary dotknięte długiem technicznym.

11) Ankiety i wywiady: Przeprowadzanie ankiet i wywiadów z zespołami programistycznymi może dostarczyć jakościowych informacji na temat postrzeganego poziomu długu technicznego oraz jego wpływu na produktywność i jakość kodu. Ponadto zbieranie opinii interesariuszy może pomóc ustalić, gdzie może być konieczne ponowne wykonanie prac.

12) Kwadrant długu technicznego: Szczególnie przydatnym narzędziem jest kwadrant długu technicznego wprowadzony przez Martina Fowlera. Kategoryzuje on przyczyny długu technicznego jako zamierzone lub niezamierzone oraz lekkomyślne lub rozważne, pomagając zespołom zrozumieć kompromisy.

Poza tymi dwunastoma sposobami mierzenia długu technicznego nie wahaj się korzystać z narzędzi do zarządzania produktem, aby pomóc zespołowi śledzić dług techniczny i zarządzać jego spłatą!

Spłacanie długu technicznego

Dużo mówiliśmy o zaciąganiu długu technicznego, ale nie omówiliśmy jeszcze, jak go spłacać. Jako menedżerowie produktu jesteśmy odpowiedzialni za pokierowanie naszymi zespołami tak, aby zdecydowały, kiedy spłacać dług, a kiedy zaciągać dodatkowy dług techniczny.

Spłacamy dług techniczny, gdy inżynierowie aktualizują bazę kodu, aby rozwiązać wcześniej zidentyfikowane problemy związane z długiem technicznym. Może to obejmować przeprojektowanie funkcjonalności w celu zwiększenia jej wydajności, wdrożenie automatycznych testów lub przygotowanie szczegółowej dokumentacji kodu.

Jednym z najlepszych sposobów na jego spłatę jest zarezerwowanie w każdym sprincie czasu na wzmacnianie bazy kodu i zmniejszanie długu. Potraktuj to jak comiesięczne raty kredytu hipotecznego — im szybciej spłacimy kredyt, tym mniej odsetek będziemy musieli zapłacić łącznie!

Dobrą zasadą jest reguła 80/20. Oznacza to, że około 80% czasu w każdym sprincie należy poświęcić na tworzenie nowych funkcji, a 20% na nadawanie priorytetu inwestycjom technicznym i usprawnieniom.

Planując spłatę długu technicznego, rozważ odpowiednie uwzględnienie go w mapie drogowej produktu.

Końcowe przemyślenia na temat długu technicznego

Podsumowując, zarządzanie długiem technicznym nie jest wyłącznie zadaniem deweloperów. Swoją rolę odgrywają menedżerowie produktu, zespoły zwinne i interesariusze biznesowi.

Ostateczny cel? Dostarczenie wysokiej jakości produktu programistycznego, który realizuje cele biznesowe bez zaciągania długu niemożliwego do utrzymania.

Tak więc, niezależnie od tego, czy zagłębiasz się w odmęty tworzenia oprogramowania, czy po prostu próbujesz zrozumieć, dlaczego Twój zespół programistyczny wciąż mówi o refaktoryzacji, zrozumienie i zarządzanie długiem technicznym to kompas, którego potrzebujesz.

Niezależnie od tego, czy dopiero zaczynasz swoją karierę w obszarze produktu, czy jesteś już doświadczonym weteranem zarządzania produktem, niemal zawsze skorzystasz na pogłębieniu swojej wiedzy na temat żargonu technicznego.

Mam nadzieję, że unikniesz błędu, który popełniłem na początku swojej kariery — nie polegaj wyłącznie na wskazówkach kontekstowych, aby zgadywać znaczenie nieznanych pojęć technicznych!

Zamiast tego poświęć czas na przeprowadzenie badań, korzystaj z zewnętrznych przewodników, takich jak ten, i spędzaj czas z inżynierami, aby odświeżyć cenną wiedzę.

Aby uzyskać więcej informacji i przewodników dotyczących zarządzania produktem, nie zapomnij zapisać się do naszego newslettera!