Jak oceniać, zarządzać i unikać długów technicznych
Opublikowany: 2020-05-26Jeśli dług techniczny brzmi jak coś wyjętego z podręcznika o finansach, to dlatego, że termin ten jest związany z finansami. Jednak w prawdziwym tego słowa znaczeniu dług techniczny jest związany z programowaniem. Chodzi o to, że podczas opracowywania projektu oprogramowania pewne niezbędne kroki są pomijane lub po prostu całkowicie odrzucane, aby dotrzymać terminu.
W dążeniu do stworzenia idealnej aplikacji lub oprogramowania, programiści często mają mało czasu – tak jak każda przypadkowa osoba wykonująca dowolne zadanie. Dlatego zwykle sensowne jest znalezienie kompromisu między dostarczaniem doskonałego produktu z doskonałym kodem a maksymalizacją czasu.
Pytanie zatem brzmi: czy istnieje granica tych kompromisów? Czy istnieją nieodłączne szkody, które mogą wyniknąć z tego kompromisu? Wreszcie, czy na dłuższą metę programista naprawdę ma się lepiej? W tym artykule o długach technicznych postaram się odpowiedzieć na wszystkie te pytania.
Co to jest dług techniczny?
Definiując dług techniczny, będziemy musieli przede wszystkim odnieść się do człowieka, któremu przypisuje się wygenerowanie tego terminu: Warda Cunninghama. Według Cunninghama, dług techniczny odnosi się do dodatkowej pracy rozwojowej, którą trzeba włożyć w zaprogramowanie kodu, aby w krótkim czasie zrekompensować deficyt wynikający z zaprogramowania go.
Aby było bardziej obrazowo, wyobraź sobie, że masz za zadanie posprzątać bałagan w pokoju i spóźniasz się na zajęcia. Aby upewnić się, że wykonasz instrukcje, a także zdążysz na zajęcia, robisz szybkie sprzątanie, zamiatając większość śmieci pod kanapę. Efektem tego jest to, że w końcu będziesz musiał poświęcić trochę czasu na uporządkowanie bałaganu. W przypadku tworzenia oprogramowania, gdy pominiesz niezbędne kroki i pójdziesz łatwiejszą ścieżką, z „nie tak czystymi” kodami, trudniej będzie później wyczyścić kod. Istnieje wiele etapów napotykanych w domino projektu oprogramowania, a im dłużej ignorujesz istniejący problem, tym dłużej trwa jego rozwiązanie.
Rodzaje długów technicznych
Długów technicznych są różnego rodzaju, w tym:
Planowane długi techniczne
Dzieje się tak w sytuacjach, gdy organizacje celowo decydują się na zadłużenie techniczne. Jest to, jak wcześniej omówiono, zwykle przekroczenie ustalonych terminów i osiągnięcie określonego celu. Angażując się w planowane długi techniczne, organizacja musi mieć jasność, z czego jest gotowa zrezygnować, a czego nie. Musisz prowadzić dokładne zapisy, pamiętając, że w końcu będziesz musiał zwrócić i poprawić błędy, które pominąłeś na początku.
Niezamierzone długi techniczne
Ten rodzaj długu technicznego jest wprost przeciwieństwem pierwszego. Powstaje, gdy organizacja nie przewiduje ani nie planuje długu technicznego. Powodem tego jest zazwyczaj zerwanie komunikacji pomiędzy różnymi jednostkami w organizacji lub kiepskie praktyki pracy pomiędzy jednostkami.
Nieuniknione długi techniczne
Jest to rodzaj długu technicznego, któremu żadne działanie ze strony organizacji nie mogłoby zapobiec. Na przykład, biorąc pod uwagę szybkie zmiany w technologii, sensowne jest, aby niektóre kody napisane w przeszłości nie spełniały przewidywanych obecnie standardów.
Ten rodzaj długu technicznego może również powstać, gdy wymagane są zmiany, gdy kod jest już pisany. Jeśli w połowie projektowania oprogramowania zostaną wprowadzone pewne zmiany, może to zepsuć dynamikę, czyniąc stary kod przestarzałym lub niepotrzebnym.
Przyczyny zadłużenia technicznego
Niektóre z przyczyn długu technicznego zostały omówione powyżej, ale wybiorę je po kolei, aby były jaśniejsze.
Pośpiech
Najczęstszą przyczyną zadłużenia technicznego jest pośpiech. Deweloperzy często mają rygorystyczne terminy, z których niektóre obejmują terminy uruchomienia określonego oprogramowania. Często w tego typu sytuacjach jest zrozumiałe (i oczekiwane), że deweloper może po drodze zaciągnąć długi techniczne. Ten rodzaj długu technicznego jest często zamierzony i może powodować problemy, które mogą obejmować błędy w kodzie lub pojawienie się kodów spaghetti.
Przeoczenie/Błąd
Czasami programiści po prostu piszą złe kody, które ostatecznie prowadzą do długów technicznych. Niezależnie od tego, czy zły kod istnieje w wyniku błędu kodera, czy nie, faktem jest, że błędy skutkują długami technicznymi, a ponieważ nie są skalowalne, w końcu będą musiały zostać naprawione.
Brak świadomości skutków
Czasami długi techniczne powstają, ponieważ koder nie zdaje sobie sprawy lub nie uznaje, jak szkodliwe są długi techniczne na dłuższą metę. Może to wynikać z uzasadnionej ignorancji szkodliwych skutków chodzenia na skróty podczas programowania lub może być świadomym lekceważeniem konsekwencji.
Zamiar
Długy techniczne mogą powstać celowo w wyniku celowych działań kodera lub organizacji.
Brak modułowości
Dzieje się tak głównie dlatego, że jeden kod może obsługiwać jednocześnie inną logikę biznesową. Taka sytuacja znacznie utrudnia obsługę oprogramowania. Z każdym kodem, który napisze programista, tym większe są szanse, że napotkają problemy z modułowością.
Wycena Długu Technicznego
Długów technicznych nigdy nie należy obliczać ręcznie, ponieważ byłoby to dość uciążliwe. Oznaczałoby to konieczność ręcznego wpisywania kodu w celu określenia bieżących problemów i ewentualnych przyszłych. Oprócz tego, jak bardzo czasochłonny jest proces ręczny, istnieje możliwość, że kody zmienią formę pod koniec procesu ręcznego.
Jednym ze sposobów przeprowadzenia ewaluacji jest przeprowadzenie analizy statycznej przy użyciu narzędzi, które ją wspierają. Niektóre z narzędzi, których można użyć, to Coverity, SonarQube, Check Style i Closure Compiler.
Generalnie istnieją dwa sposoby obliczania długu technicznego. W pierwszym podejściu można go uzyskać obliczając wskaźnik długu technicznego według wskaźnika kodu. W tym przypadku wstępne oszacowanie lub całkowity czas potrzebny na stworzenie aplikacji zostanie wykorzystany do określenia czasu potrzebnego na naprawienie długu technicznego.
W drugim podejściu możesz bezpośrednio skorzystać z szacunków podawanych przez różne narzędzia, takie jak SonarQube. Zostaną one połączone z wykazami długów technicznych oraz ich kodami referencyjnymi. Z narzędzi można uzyskać dokładne oszacowanie czasu potrzebnego na naprawę.
Oszacowanie długu technicznego da Ci wyobrażenie, ile dni zajmie naprawa długu technicznego. Im więcej długów, tym dłużej zajmie Ci ich naprawienie.
Rozwiązywanie długów technicznych
Co zrobić, jeśli pojawiły się długi techniczne i nie wiesz, co robić? Istnieją pewne kroki, które możesz podjąć, aby zarządzać długami technicznymi.
Po pierwsze, powinieneś uznać, że długi techniczne istnieją i przekazać to swojemu zespołowi. Komunikując się, powinieneś jasno określić, co się stało i co należy zrobić, aby to naprawić. Powinieneś upewnić się, że jak najszybciej zakomunikujesz sobie potrzebę załatwienia długu technicznego.
Po poinformowaniu zespołu o długach technicznych możesz podjąć trzy podejścia. W pierwszym podejściu możesz zdecydować się na kontynuację systemu bez zmian. W tym scenariuszu aplikacja będzie używana bez zmian.
Alternatywnie możesz zdecydować się na refaktoryzację aplikacji. Refaktoryzacja ma na celu zmniejszenie złożoności aplikacji, a także oczyszczenie jej struktury. Dzięki refaktoryzacji zachowanie oprogramowania nie ulegnie zmianie; jedyną dotkniętą częścią będzie struktura wewnętrzna.
Na koniec, jeśli dwie omówione powyżej opcje nie działają, będziesz musiał całkowicie zastąpić kod. Jednym z problemów jest to, że może to prowadzić do nowych długów technicznych, ale na dłuższą metę może to być lepszy kompromis.
Unikanie długów technicznych w przyszłości
Oczywiście nie ma wątpliwości, że unikanie długów technicznych jest zdecydowanie mądrzejsze niż próba ich naprawienia, gdy się pojawią. Oprócz tego, że oszczędza czas i stres, zapewnia również brak resztkowych konsekwencji, które wynikają z posiadania długów technicznych od początku.
Można argumentować, że długi techniczne same w sobie nie są złe. Są one generalnie problematyczne, ponieważ są to długi, które trzeba spłacić, a ludzie nie są najbardziej odpowiedzialnym gatunkiem na ziemi. Konsekwentne wybieranie słabszej opcji ogólnie osłabi siłę twojego oprogramowania i utrudni późniejsze ulepszanie funkcjonalności. Podsumowując, unikanie długów technicznych jest najlepszym rozwiązaniem dla każdego.
Jak więc zapobiec powstawaniu długów technicznych:
Chodzi o to, aby wszyscy byli na bieżąco z procesem i skrócili ich do wymagań dotyczących wykonywanych zadań. Tworząc backlog, każdy może zobaczyć zadania, które nie zostały wykonane, oraz ścieżki ich realizacji.
Jeśli sam jesteś programistą, musisz nauczyć się przedkładać wysokiej jakości pracę nad dużą ilością pracy. Upewnij się, że Twoje kody są czyste, a Twoje aplikacje lub inne oprogramowanie są opracowane do perfekcji. Zrozum, że pokusa pójścia na skróty nie będzie tego warta, ponieważ w końcu nadal będziesz musiał wykonywać zadania, które porzuciłeś.
Jeśli kierujesz zespołem, musisz przekazać te same wartości członkom zespołu. Członkowie powinni być uczeni tworzenia rozwiązań zorientowanych na wyniki i unikania skrótów.
Ogólnie rzecz biorąc, dogłębna wiedza na temat tego, czym jest dług techniczny i jak go uniknąć, może być przydatna w zapobieganiu ich powstawaniu. Kiedy uzbroisz swoich programistów w niezbędną wiedzę, lepiej unikną pułapek, jakie stwarzają długi techniczne.
Niektóre praktyki kodowania zwiększają prawdopodobieństwo popadnięcia w dług techniczny. W związku z tym byłoby wspaniale unikać ścisłego sprzężenia, zastosować abstrakcję i refaktoryzację.
Regularne aktualizacje technologii mogą być doskonałym sposobem na uniknięcie długów technicznych. Podczas aktualizacji musisz upewnić się, że używane są najnowsze frameworki, bazy danych i oprogramowanie aplikacyjne.
Wniosek
Długów technicznych w ogromnej większości przypadków nie da się uniknąć, o ile nadal tworzysz programy i piszesz kody. Jednak szanse ich wystąpienia można znacznie zmniejszyć, wykonując czynności wymienione powyżej. Również w przypadku długów technicznych nie traci się nadziei. Zachowaj spokój, bądź pewny siebie, działaj odpowiednio.