Dług techniczny jest jak Tetris
Uwielbiam Tetris, podobnie do większości ludzi, którzy w to grali. Tetris to nie tylko jedna z najlepszych gier wszechczasów, ale także doskonała analogia długu technicznego. Skutki długu technicznego są czymś, z czym jestem głęboko zaznajomiony — radzę sobie z nimi każdego dnia. Podzielę się również historią o tym, jak mój zespół i ja zmniejszyliśmy dług techniczny, naprawiając błąd, który kosztował firmę 1 milion dolarów rocznie.
Zadania są łatwiejsze na początku, gdy złożoność jest niska
W firmach programistycznych menedżerowie produktów i projektów współpracują z programistami, aby ustalić, jaki kod zostanie następnie napisany i wysłany do klientów. Ukończenie jednego wiersza w Tetrisie jest jak dostarczenie małej funkcji. Wysyłka złożonej funkcji wymaga więcej wierszy.
Złożone funkcje są satysfakcjonująco łatwe przy niskim długu technicznym
Często potrzeby biznesowe (nowe funkcje, nowe produkty) doprowadzą do kompromisów w ramach kodu (hacki, pójście na skróty) w celu dostarczenia czegoś na czas. Istnieje również prawdopodobieństwo, że zmiany w strategii produktu będą niezgodne z poprzednimi założeniami, co będzie wymagało dodatkowego wysiłku w celu migracji klientów lub obsługi zarówno „nowej”, jak i „starej” logiki.
Niewielkie ilości długu technicznego są normalne i możliwe do zarządzania
Takie scenariusze powodują zadłużenie techniczne w ramach kodu produktu. Zagrzebana luka na planszy Tetrisa stanowi dług techniczny. Cały kod ma dług techniczny. To normalne. Możesz przecież grać w Tetris z kilkoma lukami.
Po uszy w długu technicznym
Zbyt wysoki dług techniczny uniemożliwia wysyłanie funkcji i poprawek błędów w rozsądnym czasie. Nie jest to problem, który można rozwiązać, dodając więcej programistów lub, bardziej radykalnie, zastępując istniejących. Nazywa się to długiem technicznym, ponieważ w pewnym momencie należy go spłacić. Spłata długu technicznego zapewnia konkurencyjność i sprawia, że możesz dalej grać.
Koniec gry
Podobnie do prowadzenia firmy, Tetris staje się trudniejszy, im dłużej grasz. Klocki poruszają się szybciej i trudniej jest nadążyć. Podobnie jak w przypadku prowadzenia biznesu, w Tetris nie wygrasz. Kontrolujesz tylko to, jak szybko przegrasz. Podobnie jak w przypadku prowadzenia biznesu, zbyt wiele luk na planszy Tetrisa spowoduje, że przegrasz.
Błąd o wartości 1 000 000 $
Nie tak dawno temu mojemu zespołowi powierzono zadanie aktualizacji logiki rozliczeń i fakturowania w naszym kodzie produktu w celu obsługi nowych planów cenowych, nowego procesora płatności oraz usprawnienia przepływu płatności. Niektóre szczegóły wciąż były ustalane przez zespół produktowy, więc wykorzystaliśmy wolny czas, aby zagłębić się w istniejący kod. Lepiej rozumieliśmy nasz kod, dzięki czemu moglibyśmy podać dokładne oszacowania naszej zdolności do wprowadzenia nadchodzących zmian.
Podstawowym celem kodu, który zbadaliśmy, było sprawdzenie konta każdego klienta, obliczenie jego rachunku i przesłanie go do API fakturowania. Ktoś się wyraźnie przyłożył do napisania tego kodu, był on jednak dosyć nieelastyczny. To był monolit, nie było testów i mieliśmy bardzo mało logów. Nie było prawie żadnej dokumentacji. Nastąpiła niewyjaśniona losowość. Kod ten został napisany ponad pięć lat wcześniej przez jednego ze współzałożycieli. Jedyne zmiany od tego czasu były naniesione przez wczesnego pracownika, którego nie było już w firmie.
Czy to naprawdę był problem? Faktury były wystawiane, a firma zarabiała pieniądze. Nic nie wskazywało na problem. Wszystko to mogło odwieść nas od refactoringu, ale wiedzieliśmy, że nadchodzą duże zmiany. Funkcja ta nie była dostosowana do naszych potrzeb i mogła nas spowolnić. Przeprowadziliśmy refaktoryzację tej funkcji w ramach jednego sprintu i dodaliśmy kilka bardzo potrzebnych logów. Wtedy odkryliśmy, co tak naprawdę naprawiliśmy. Ktoś z księgowości zapytał, dlaczego liczba faktur wychodzących niespodziewanie wzrosła.
Stary kod po cichu kończył się timeoutem, przez co klienci, pomimo używania usługi, nie dostawali faktur. A ta dziwna losowość? Ukryła ona wszelkie wzorce, które mogły nas ostrzec przed klientami, którym nie wystawiono faktur. Według oszacowania brakujące faktury wyniosły ponad 1 000 000 dolarów rocznie.
Spłacanie długu nie zawsze się opłaca
Chociaż powyższa historia jest całkowicie prawdziwa, spłata długu technicznego nie zawsze ma tak dramatyczny skutek. Mieliśmy szczęście.
Znajdź odpowiednią równowagę długu technicznego
Chciałbym mądrze doradzić, kiedy spłacić dług techniczny. Niestety odpowiedź jest skomplikowana i zawsze będzie działaniem równoważącym. Możesz mieć najczystszy, najlepiej przetestowany kod na świecie, ale bez płacących klientów. I na odwrót, Twoja firma może mieć naprawdę niechlujny kod, który jednak zachwyca klientów i zarabia pieniądze.
Tak czy siak, product ownerzy i programiści powinni zrozumieć, czym jest dług techniczny. Powinni też wiedzieć, że nie można go zawsze unikać. W końcu podobnie, jak w Tetris, nie można wygrać w grze w oprogramowanie.
Oryginał tekstu w języku angielskim przeczytasz tutaj.