Zła karma w programowaniu. Co to jest dług techniczny i jak go naprawić

Dług techniczny. Większość programistów aktywnie pracujących w swojej specjalności ma do czynienia z tym terminem. Dla wielu wspomnienie o nim może wywołać nawet ból głowy, a także dyskomfort w innych częściach ciała, który pojawia się, gdy w trakcie pracy nad projektem dotknie Cię dług techniczny. Dlatego dziś porozmawiamy o długu technicznym (TD): czym jest, jak się objawia, jakie są rodzaje długu technicznego i jak skutecznie nim zarządzać.

Co to jest dług techniczny?

Najpierw jednak zapoznajmy się z terminologią. Dług techniczny to metafora inżynierii oprogramowania opisująca problemy nagromadzone w kodzie lub architekturze oprogramowania z powodu zaniedbania jakości w rozwoju oprogramowania i powodujące dodatkowe koszty pracy w przyszłości. Taką definicję długu technicznego podaje Wikipedia. Najprościej mówiąc, dług techniczny jest efektem stosowania w rozwoju uproszczonych i krótkotrwałych rozwiązań, które później prowadzą do coraz większych (o ile oczywiście dług nie zostanie „spłacany”) kosztów pieniędzy i czasu na późniejsze udoskonalenia, przepisanie kodu lub utrzymanie produktu w dotychczasowej formie. W świecie zwykłych programistów dług techniczny jest jednym z rodzajów negatywnej karmy, demotywatorem i źródłem smutku, który pojawia się jako odpłata za zły kod, użycie kul i „tymczasowych” (ale w rzeczywistości niezbyt) rozwiązań, które pomóc rozwiązać doraźne problemy i przyspieszyć rozwój „na kredyt”, czyli kosztem narastającej plątaniny problemów w przyszłości. W branży IT dług technologiczny jest dość poważnym problemem. Według jednego z ostatnich badań firmy na całym świecie wydają co roku ponad 85 miliardów dolarów rocznie na naprawianie złego kodu. Łącznie na projekty związane ze wsparciem przestarzałych systemów i „złego” oprogramowania wydaje się około 300 miliardów dolarów rocznie. To są znaczące liczby. Naukowcy szacują, że gdyby wysiłki wszystkich deweloperów, którzy borykają się z długiem technicznym i jego konsekwencjami, skupili się na „właściwym” rozwoju, w ciągu bieżącej dekady światowy PKB zwiększyłby się o około 3 biliony dolarów.

Powody pojawienia się

Należy zrozumieć, że dług technologiczny nie zawsze jest czymś złym, tak samo zadłużenie finansowe może być pozytywne, jeśli na przykład zaciągniesz pożyczkę na rozwój biznesu (lub uruchomisz startup ). W przypadku TD jest to akceptowalne w przypadku szybko rozwijających się firm, które muszą szybko i często wypuszczać na rynek nowe produkty lub usługi, aby np. ocenić swój sukces i zbadać potrzeby rynku lub szybko zdobyć nowe nisze. Ale podobnie jak w przypadku długu finansowego, w przypadku długu technicznego należy zachować ostrożność i wiedzieć, jak nim zarządzać, w przeciwnym razie mogą pojawić się poważne problemy. Im więcej długu technicznego narosło w trakcie rozwoju oprogramowania, tym bardziej może on wpłynąć na firmę, spowalniając wydawanie nowych wydań, obniżając morale zwykłych programistów, którzy są odpowiedzialni za „utrzymanie” takiego długu i zwiększając koszty , co ostatecznie może nawet zniszczyć firmę . Przyczynami powstania długu technicznego, oprócz szlachetnej chęci jak najszybszego ukończenia produktu lub zadowolenia użytkowników nowym wydaniem, są często złe zarządzanie produktem, nierealistyczne terminy lub ograniczenia zasobów i oczywiście lenistwo programistów , w połączeniu z niskimi kwalifikacjami i brakiem zrozumienia kluczowych zasad rozwoju, również często przyczynia się do wzrostu zadłużenia. Często zdarza się, że sami deweloperzy doskonale zdają sobie sprawę z istnienia i ciągłego narastania długu technicznego, ale nie mają wystarczającej mocy, aby to zmienić lub nie są w stanie przekazać kierownictwu informacji o istnieniu takiego problemu i konieczności jego rozwiązania.

Klasyfikacja

Jak wspomniano powyżej, dług technologiczny występuje w wielu różnych formach, a ponieważ sama definicja jest jedynie metaforą, różne rodzaje długu technicznego można klasyfikować na różne sposoby. W szczególności Dag Liodden, współzałożyciel i CTO firmy Tapad, uważany za jednego ze światowych ekspertów w dziedzinie długu technicznego, podczas przemówienia na corocznym wydarzeniu CTO Summit zaproponował podział długu technicznego na trzy główne typy.

1. Celowy dług techniczny.

   Pojawia się w przypadkach, gdy programiści świadomie wybierają nie najlepsze rozwiązanie, ponieważ jest ono łatwiejsze i szybsze w wdrożeniu, co z kolei pomoże szybko wypuścić nowy produkt na rynek.

   „Czasami celowo zaciągamy dług techniczny, aby skrócić czas rozwoju. Jeśli zdecydujesz się pójść tą drogą, weź pod uwagę nie tylko czas, który zaoszczędzisz w trakcie rozwoju, ale także czas, który będziesz musiał później poświęcić na „spłatę” takiego zadłużenia. Upewnij się także, że interesariusze [najwyższe kierownictwo firmy] mają świadomość, że taka decyzja nieuchronnie spowolni uruchomienie innych funkcji w przyszłości” – powiedział Dag Ljodden.

   Podejście do rozwiązywania tego typu długu technicznego

   Ekspert radzi dokładnie dokumentować takie przypadki, aby móc do nich wrócić i je skorygować, zanim dług techniczny przepadnie i stanie się integralną częścią struktury projektu.

2. Dług techniczny, który jest przypadkowy lub wynika z przestarzałej architektury projektu.

   Również dług techniczny często powstaje z biegiem czasu, na skutek błędów i niedociągnięć już na etapie tworzenia architektury projektu. W miarę ewolucji systemów i zmiany wymagań oprogramowania błędy projektowe stają się coraz bardziej widoczne, a dodawanie nowych funkcji wymaga więcej czasu i wysiłku. Jakość początkowej architektury projektu odgrywa tutaj ważną rolę – powinna być zarówno prosta, jak i funkcjonalna, wtedy łatwiej będzie dostosować się do zmian.

   Podejście do rozwiązywania tego typu długu technicznego

   Aby zapobiec narastaniu tego typu długu technicznego i nie przekraczaniu jego poziomów krytycznych, Dag Llodden zaleca regularną refaktoryzację – mniej więcej raz na dwa lata, w okresach, gdy system jest w stabilnym stanie. Liderzy zespołów i menedżerowie produktu muszą przeznaczyć czas na „spłatę” tego rodzaju długu technicznego, który powstaje na skutek architektury i często zmieniających się wymagań wobec projektu.

3. Dług technologiczny powstający w czasie.

   Ekspert nazywa taki dług techniczny „długo gnijącym”. Kumuluje się z biegiem czasu, gdy komponent lub system stopniowo staje się bardziej złożony ze względu na ciągłe dodawanie wielu zmian. Sytuacja często ulega pogorszeniu, jeśli nad systemem na różnych etapach pracują różni ludzie i nie w pełni rozumieją oryginalną architekturę.

   Podejście do rozwiązywania tego typu długu technicznego

   To jedyny z trzech rodzajów długu technicznego, którego należy na bieżąco unikać poprzez regularną refaktoryzację – mówi ekspert. W idealnym przypadku zespół programistów powinien poświęcić trochę czasu na dokładne zrozumienie architektury systemu, nad którym pracuje, nawet jeśli został pierwotnie stworzony przez inne osoby. Zrozumienie systemu pozwoli Ci stopniowo ulepszać i poprawiać zły kod, nie doprowadzając projektu do etapu „gnicia”.

Rozwiązania techniczne w zakresie zarządzania długiem

Istnieje wiele możliwości skutecznego zarządzania długiem technicznym, ale wszyscy eksperci zgadzają się, że należy to zrobić, ponieważ dług techniczny jest integralną częścią niemal każdego rozwoju, a firmy, które go ignorują, niezmiennie napotykają problemy na późniejszych etapach. Oto kilka skutecznych rozwiązań i podejść do zarządzania długiem technicznym dla zespołu programistów.

1. Przeznacz stały procent swojego czasu pracy na pracę nad długiem technicznym.

   Problem z długiem technicznym jest taki, że nigdy nie ma czasu na pracę nad jego wyeliminowaniem (ponieważ zawsze są zadania o wyższym priorytecie), chyba że robisz to celowo. Dlatego dobrym rozwiązaniem byłoby przeznaczyć na te cele określony procent czasu pracy – około 20-25%.

   Można to zrobić na różne sposoby.

2. Praca nad długiem technicznym 1 dzień w tygodniu

   Если выделять на работу над устранением ТД всей командой один день в неделю, это Jak раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усLubям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что kodеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда Jak коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, Jak выяснLub заокеанские kodеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том Lub ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на prędkość разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти Jak снежный ком.

Заключение

Na koniec jeszcze raz chciałbym podkreślić, że nie da się obejść bez długów technicznych w rozwoju oprogramowania, ponieważ są one integralną częścią rozwoju jako takiego. Jednak pomimo swojego technicznego charakteru, TD nadal stanowi problem powodowany przez czynnik ludzki w rozwoju. I choć nie obejdzie się bez tego całkowicie, wielkość długu technicznego można maksymalnie zmniejszyć, jeśli napiszesz „czysty” kod i podejdziesz do procesu rozwoju w sposób możliwie odpowiedzialny i profesjonalny. Tego właśnie życzymy każdemu!