Czym jest dług techniczny i czy można go uniknąć?

Jeśli zajmujesz się tworzeniem oprogramowania, w pewnym momencie będziesz musiał poradzić sobie z długiem technicznym. Odpowiadając na pytanie w tytule… nie, nie da się tego uniknąć. Istnieją jednak kroki, które możesz podjąć, aby zminimalizować jego skutki i upewnić się, że nie wymknie się spod kontroli. Przynajmniej za bardzo.

Co to jest dług techniczny?

Dług technologiczny, jak to się czasem nazywa, jest zasadniczo kosztem, jaki ponosisz z biegiem czasu z powodu niedoskonałego kodu. Zmiany i aktualizacje kodu źródłowego mają swoją cenę, podobnie jak dodanie nowego członka do zespołu programistów, dodanie nowej funkcji lub naprawianie błędów i łatanie exploitów.

W miarę jak Twój projekt staje się większy, baza kodu się rozszerza i coraz więcej osób pracuje nad tym kodem, ich głosy i style będą się tu i ówdzie kolidować. Być może masz ostateczny termin i mniej niż idealne rozwiązanie zostało załatane w kodzie źródłowym, aby zakończyć na czas. Być może dodajesz komponent typu open source, którego nie rozumiesz w pełni, aby obsługiwać funkcję, zamiast samodzielnie ją kodować. Możesz też przełączać biblioteki między wersjami (na przykład od Backbone do React), ale nadal musisz wspierać ludzi korzystających ze starszej bazy kodu dla swoich projektów.

Absolutnie żadna z tych rzeczy nie jest zła . Nie na własną rękę. Może wcale. Ale po zsumowaniu zaciągnięty przez nich dług techniczny będzie musiał zostać spłacony w pewnym momencie w przyszłości.

W pewnym momencie ten komponent open source może wymagać wymiany (lub rozwidlenia). To będzie kosztować czas i pieniądze. W odległej przyszłości będziesz musiał usunąć cały kod Backbone ze swojego projektu i przestać wspierać starszych użytkowników. Znowu czas i pieniądze. Ta łatka, którą zrobiłeś, żeby dotrzymać terminu? Cóż, w końcu się cofnie i będzie wymagało bardziej trwałej naprawy. Czas i pieniądze. Będziesz mieć nowych członków swojego zespołu, którzy przejdą do starego kodu, aby zrobić to wszystko, i będą musieli zrozumieć kod i logikę poprzednich deweloperów. Czas. Pieniądze.

Kumasz.

Podczas gdy dług techniczny jest pojęciem abstrakcyjnym, często metaforycznym, koszt długu technologicznego jest bardzo realny. Spłata ma wartość pieniężną i możesz śledzić odsetki, które płacisz, w godzinach pracy i odcinkach wypłat. Możesz to zobaczyć w dolnej linii całego rozwoju oprogramowania.

Czy można uniknąć zadłużenia technologicznego?

Jak powiedziałem wcześniej… nie do końca, nie. Jeśli kiedykolwiek wrócisz do kodu po jego wydaniu, narosniesz dług techniczny w każdym projekcie, który napiszesz. Jeśli jednak rozbijesz rodzaje długu technicznego, możesz je zminimalizować, a nawet uwzględnić w swoich projektach. Jeśli weźmiesz pod uwagę dług wcześniej, nie różni się to od zaciągnięcia kredytu samochodowego lub kredytu hipotecznego. Patrzysz na koszt, odsetki i korzyści, a następnie decydujesz, czy możesz/chcesz je zapłacić.

Przyjrzyjmy się niektórym przykładom, które omówiliśmy powyżej, i zobaczmy, czy istnieje sposób na uniknięcie, zminimalizowanie lub zaabsorbowanie kosztów.

Biorąc pod uwagę celowy dług techniczny

Kiedy mówimy o celowym długu technicznym, mamy na myśli to, że Twój zespół podjął decyzje, o których wiesz, że nie mieszczą się w tak zwanych najlepszych praktykach dotyczących języka lub typu projektu, nad którym pracujesz. Wspomnieliśmy wcześniej, że możesz mieć termin do dotrzymania. A może ten termin jest trudny i szybki. Być może istnieje 0% szansy na zmianę lub przesunięcie.

To wtedy trzeba rozważyć zaciągnięcie kredytu i zaciągnięcie długu technicznego.

Naprawdę masz tutaj trzy opcje:

• Opublikuj oprogramowanie, które jest niedokończone i zawiera błędy, ale nie idziesz na żadne ustępstwa w kwestii przejrzystości i logiki kodu
• Pociągnij funkcje, których nie możesz udoskonalić, ale uwolnij to, co masz, co jest tak dobrze napisane, jak to możliwe
• Podejmuj decyzje programistyczne, które wypuszczają „wystarczająco dobry” kod, aby wszystko działało, ale prawdopodobnie będą musiały zostać ponownie rozwiązane później

Trzecia opcja jest często wybierana przez ludzi. To idzie w dług techniczny. I nie ma w tym nic złego. Ponieważ podjąłeś decyzję, żeby to zrobić .

Spłata celowej pożyczki dłużnej

Upewnij się, że w swoim kodzie udokumentowałeś decyzje stojące za wyborem przejścia tą drogą. Rób notatki na temat tego, co zrobiłeś, a jakie byłoby idealne rozwiązanie. I upewnij się, że zamieściłeś w kodzie źródłowym przynajmniej jakiś komentarz, aby wskazać, gdzie wdrożono to rozwiązanie do obsługi długów (i jeśli wiesz, jakie systemy dotyczyły innych obszarów projektu). Jeśli nie zrobisz tego kroku, dodanie do projektu (nawet w poprawkach błędów i łatach, nie wspominając o nowych funkcjach lub rozszerzonej bazie kodu) może być strasznie opóźnione przez znalezienie rozwiązania patchworkowego, gdy oczekujesz kompletnego.

Ponownie, to patchworkowe rozwiązanie może być całkowicie w porządku i nigdy nie sprawić żadnych prawdziwych problemów. Ale dług techniczny nadal istnieje i należy go rozliczyć.

Biorąc pod uwagę dług techniczny Legacy Code

Innym powszechnym rodzajem długu technicznego jest ten, którego WordPress gromadzi obecnie dużo. WordPress może działać na PHP 5.x. Najnowsza aktualizacja powie jednak użytkownikom, że musi to być przynajmniej PHP 5.6. Do końca 2019 r. WP Core będzie wymagał PHP 7.x. Jednak podnosząc wymagania, wiele starego kodu musi zostać zaktualizowanych. Ponieważ wciąż jest kod PHP 5.x we wtyczkach, motywach i samym rdzeniu.

Nie wspominając o nowym edytorze bloku. Jest napisany w JavaScript. Reaguj konkretnie. To nic w pobliżu PHP. W rzeczywistości znaczna część rdzenia WordPressa jest stopniowo przepisywana na JavaScript. Ale wszystko to JS musi być również komplementowane i dogadać się z PHP. Przyjmowanie nowej technologii jest wspaniałe i konieczne jest przyjęcie nowych wymagań dotyczących wersji. Ale robiąc to, płacisz odsetki od nieuniknionego długu technicznego, który zaciągasz z powodu tego oprogramowania, które istnieje od jakiegoś czasu.

Spłacanie zadłużenia wynikającego ze starszego kodeksu

Ten jest dość trudny, ponieważ nie ma na to świetnego sposobu. Możesz wziąć opcję nuklearną i całkowicie przepisać od podstaw w nowym języku/frameworku/wersji (spójrz na to, co zrobiliśmy między Divi 2 i Divi 3.0, przechodząc z Backbone.js do React). To jednak nadal nie rozwiązuje całkowicie problemu zadłużenia, ponieważ nadal masz ludzi korzystających ze starej biblioteki. W pewnym momencie będziesz musiał zrezygnować ze wsparcia dla starszej bazy kodu. To jest trochę jak spłacanie pożyczki. Dopóki nie będziesz musiał wyjąć następnego.

Jeśli to nie jest opcja (lub najlepszy pomysł dla Ciebie), możesz upewnić się, że nie polegasz na funkcjach specyficznych dla języka lub wersji. Deweloperzy front-endu muszą sobie z tym poradzić cały czas, ponieważ niektóre przeglądarki szybko obsługują zupełnie nowe funkcje, podczas gdy inne (Microsoft Edge/IE, kaszel) mogą nigdy ich nie przyjąć. Możesz zabezpieczyć swoje projekty na przyszłość, trzymając się podstaw, co z kolei spowoduje, że liczba zmian, które należy uwzględnić podczas aktualizacji lub refaktoryzacji, będzie mniejsza niż w innym przypadku.

Biorąc pod uwagę wielu programistów w czasie

Jest to rodzaj długu technologicznego, który duże zespoły z czasem narastają gorzej niż małe zespoły programistów. Chociaż nawet małe muszą się tym martwić. Widzisz, każdy inżynier oprogramowania pisze kod inaczej. Bardzo rzadko będziesz miał dwóch programistów, którzy rozwiążą ten sam problem za pomocą dokładnie tego samego kodu. Mogą pełnić tę samą funkcję, a efekt końcowy może być taki sam, ale kod zostanie napisany głosem autora (tak jak możesz tutaj stwierdzić, kto napisał posty, na przykład Jason, Nathan, Donjete i Wszyscy mam różne style). Kod nie jest inny.

Mając to na uwadze, logika może czasami mieć różne głosy. To, co jeden programista myśli, jest całkowicie jasne, inny programista przyjrzy się i nie będzie miał pojęcia, dlaczego kod robi to, co robi. Ta kwestia staje się naprawdę problematyczna, gdy oryginalny autor nie jest już dostępny do konsultacji. Narosły dług techniczny może być katastrofalny. Ale są sposoby, by sobie z tym poradzić.

Spłacanie długu technicznego starych deweloperów

Najłatwiej jest zatrudnić najlepszych programistów i nigdy nie pozwolić im opuścić Twojej firmy. Kiedykolwiek.

Ponieważ nie zdarza się to w 100% przypadków, spłatę tego długu można złagodzić nieco łatwiej, niż mogłoby się wydawać. Przede wszystkim upewnij się, że wyszkolisz swój zespół programistów w komentowaniu ich kodu. I dobrze to skomentować. Za każdym razem, gdy podejmą decyzję, która może być nawet w pewnym stopniu uznana za niejednoznaczną przez kogoś innego, poproś ich, aby odnotowali, dlaczego to zrobili i jak działa funkcja.

Dodatkowo upewnij się, że każdy programista w twoim zespole trzyma się przewodnika stylu lub zestawu standardów. WordPress Core ma zestaw standardów kodowania, które utrzymają wtyczki, motywy i wkłady Core, aby każdy, kto przyjdzie później, nie miał z tym problemów. Airbnb ma przewodnik po stylu React, który został przyjęty jako nieoficjalny standard w całej branży. Nawet wewnętrzne przewodniki po stylu i standardy powstrzymują deweloperów przed posuwaniem się zbyt daleko na własną rękę, ponieważ tego rodzaju zmiany nie zostaną scalone, chyba że będą szykować się do tabaki.

Zawijanie

Dług techniczny to bardzo realny problem. To także bardzo realny zasób, jeśli wiesz, jak nim zarządzać. Dzięki możliwości decydowania, kiedy zaciągasz dług technologiczny i jak go spłacasz, Twój rozwój może przebiegać szybciej i płynniej, niż byłoby to możliwe w innym przypadku. Mamy nadzieję, że w tych czasach, w których podjęcie tego ciężaru jest nieuniknione, mamy nadzieję, że przedstawiliśmy Wam kilka pomysłów na strategie, które można wdrożyć, aby zmniejszyć jego wpływ, niż mógłby być w innym przypadku.

Jak radzisz sobie z długiem technicznym w swoich projektach i zespołach deweloperskich?

Artykuł wyróżniony obrazem autorstwa Andrey Suslov/ shutterstock.com