Dług technologiczny

Krzysztof Kempiński
Sep 14 · 17 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Dawidem Yerginyan o długu technologicznym.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość to Senior Software Developer w Boldare. Od kilku lat zajmuje się budową produktów cyfrowych dla klientów zagranicznych, głównie w branży energii odnawialnej. Jego obszarem specjalności są technologie backendowe i rozwiązania devopsowe. Miał też okazję współtworzyć popularne opensourcowe narzędzie Marble.js. Aktywnie dzieli się swoją wiedzą, biorąc udział w webinarach, warsztatach i meetupach branżowych, m.in. dev.js czy No Exceptions. Moim i Waszym gościem jest Dawid Yerginyan.

Cześć, Dawid! Bardzo miło mi gościć Cię w podcaście.

Cześć Krzysiek! Witam wszystkich, którzy będą słuchaczami.

Dzisiaj z Dawidem będę rozmawiał o rzeczy, która występuje w każdym projekcie, nawet typu greenfield. Nawet w drugim dniu jego istnienia, jak się okazuje, czyli o długu technologicznym.

Ale zanim do tego przejdziemy, to standardowy punkt programu zakłada, że pytam mojego gościa o to, czy słucha podcastów i jeśli tak, to może jest w stanie podzielić się listą ulubionych. Jak to jest u ciebie, Dawidzie?

Odpowiem tak, że znam ten standardowy element Twojego programu, co już w jakiś sposób sygnalizuje, że słucham podcastów. Aczkolwiek muszę powiedzieć, że nie jestem aktywnym słuchaczem, a na pewno nie wszystkiego, czego słucham.

Jedyny podcast, który mnie wciągnął tak, że słucham od deski do deski, to jest Better Software Design, zdecydowanie. W czasach kiedy ten podcast był jeszcze aktywny, słuchałem Developer On Fire, taki bardzo pamiętny odcinek był z Alberto Brandolinim na temat EventStormingu. Niestety autor podcastu przestał być aktywny, wyłączył chyba nawet swojego Twittera i stwierdził, że już nie będzie w ogóle brał w tym udziału. Z branżowych jeszcze Porozmawiajmy o IT też słucham.

Dzięki!

Ostatnio to, co przykuło moją uwagę, to był odcinek na temat site reliability engineering, bardzo fajny, polecam!

A tak pozabranżowo ostatnio zainteresowałem się podcastem, który nazywa się The Strong Towns, i jest to podcast, który próbuje wytłumaczyć, jak urbanistyka państw Ameryki Północnej źle wpływa na ich gospodarkę. Tak że jak ktoś jest zainteresowany, to polecam.

Szeroki przekrój. Dzięki wielkie!

Dobrze. Na początku zaczniemy może od pewnych definicji, czyli właściwie od określenia czym jest ten dług technologiczny, czym jest technical debt, u o kogo zaciągamy ten dług, jak to po prostu działa?

Dług technologiczny, czy techniczny, myślę, że można spokojnie używać tych słów zamiennie — nie wiem, które jest poprawne, zakładam, że technologiczny.

W skrócie można powiedzieć, najprostszymi słowami, że jest to coś, co trzeba będzie zapłacić w przyszłości. Ktoś będzie musiał to zapłacić. Nie dotyczy to tylko kodu, to mogą być różne składowe oprogramowania, jakaś architektura, infrastruktura, takie rzeczy.

Można porównać ten dług technologiczny do takiego długu finansowego, stąd chyba wzięło się to pojęcie. Po prostu jakiś dług, wygenerowany w naszych, można powiedzieć, artefaktach oprogramowania trzeba spłacić, bo jeżeli się go nie spłaci, to będzie generował jakieś odsetki, które będą na nas wpływać w jakiś sposób. Kogo może dotknąć? Przepraszam, pytanie było, u kogo dług zaciągamy.

Tak.

Tak naprawdę wydaje mi się, że dług zaciągamy, choć nie wiem, czy ty się ze mną zgodzisz, u zespołu developerskiego, dlatego że to on jest tym, który będzie go spłacał. Niezależnie od tego, czy to jest zespół outsource’owy, czy to jest zespół inhouse’owy, to raczej oni będą, że tak powiem, dealować z tym długiem technologicznym.

Tak, zgadzam się absolutnie. To jest zaciąganie długu u tych, którzy będą w przyszłości pracować nad tym projektem. W jakimś tam szczególnym przypadku to możemy też być my po prostu, autorzy, też się tak zdarza.

Zresztą ja mam takie prywatne zdanie, że nie ma niczego złego w dłuższej pracy nad jednym projektem, bo to pozwala właśnie nam się zderzyć z tymi decyzjami, które kiedyś podjęliśmy i musimy teraz żyć z ich konsekwencjami. To jest więc fajna możliwość, nie tylko odpalanie co chwilę nowych projektów, ale też właśnie przez jakiś czas popróbowanie swoich sił w tych projektach, które trwają nieco dłużej.

Chciałem teraz trochę odbić piłeczkę, bo nie wiem, czy się ze mną zgodzisz, ale w takim powszechnym mniemaniu dług technologiczny, technical debt jest kojarzony z tymi właśnie projektami, trwającymi już jakiś czas, tzw. brownfield. Czyli że tutaj już wiele lat się to wszystko rozwija, wielu developerów maczało tam swoje palce w tym kodzie, no i ten dług technologiczny narasta.

Właśnie, chciałbym cię zapytać, czy ty się z tym zgodzisz, że to faktycznie jest domeną tych już takich leciwych projektów. I dopytać może też, jak i właściwie, dlaczego dług technologiczny powstaje?

Czy jest to domeną wyłącznie takich długoletnich typu brownfield? Ja uważam, że nie. Mogę powiedzieć tylko, że na pewno one są bardziej podatne na takie znaczne obciążenie tym długiem, stąd biorą się te wszystkie nasze historie o legacy strasznym itd. Bo faktycznie im dłużej projekt trwa, im więcej osób się w nim zmienia, tym łatwiej jest o takie właśnie smaczki, gdzie ktoś coś pozostawi, nie zostanie to udokumentowane, później ktoś inny musi się z tym bawić, ale moim zdaniem nie.

Dla mnie dług technologiczny to jest w ogóle taki naturalny efekt związany z rozwojem oprogramowania, chociażby dlatego, że on często kojarzy się z tym, że podejmujemy jakąś złą decyzję, nie wiedząc o niej albo podejmujemy ją nawet świadomie, z premedytacją na zasadzie: „teraz zrobimy to prościej, pójdziemy na skróty, skleimy dwa komponenty taśmą, a później w przyszłości będziemy chcieli to odkręcić”. Ale na dług technologiczny wpływa też taki efekt, że tak naprawdę wiedza, którą zdobędziemy w przyszłości, może podważyć nasze dzisiejsze decyzje. Czyli to, że ja dzisiaj się zdecyduję na stworzenie aplikacji w architekturze np. modularnego monolitu, w przyszłości może się na mnie odbić i stwierdzić, że to nie powinno być w ogóle tak.

Tak że i w projektach greenfieldowych też może narastać dług technologiczny. Jest to związane z ciągłym rozwojem oprogramowania. On np. może powstać już na samym starcie, w pierwszych miesiącach życia produktu, bo wtedy najczęściej robimy jakieś prototypy, MVP, jest najwięcej zmian, jakichś pivotów. Wtedy też często jest duża presja czasu, bo np. chcemy wypuścić jakiś produkt już, od razu, najszybciej jak się da, żeby on zaczął zarabiać albo żeby w ogóle go przetestować. Tak jak już mówiłem, możemy też zaciągać ten dług z premedytacją, na zasadzie: „teraz pójdziemy sobie na skróty, szybciej wypuścimy nasz produkt, a poprawimy to później”.

Wpływa na to też, nie wiem, czy słyszałeś takie pojęcie jak bit rot albo code rot. Chodzi o to, że z czasem, jak oprogramowanie nie jest utrzymywane w żaden sposób, to można powiedzieć, że ono gnije, rozkłada się, to jest takie pseudo stwierdzenie. Jak będziesz chciał posłuchać, to mogę potem opowiedzieć o tym jeszcze, ale chodzi o to, że oprogramowanie, które zostaje pozostawione samopas i nikt go nie wspiera, wiadomo, dezaktualizują nam się jakieś komponenty, dependency itd. Może się okazać, że jak ktoś będzie chciał za dwa lata coś zrobić w tym projekcie, to on się np. w ogóle nie zbuduje.

No właśnie, to jest bardzo mądre, co powiedziałeś. Po pierwsze uczymy się projektu, pracując w nim. Pomiędzy bajki można włożyć coś takiego, że architekturę jesteśmy w stanie zaplanować sobie w tym pierwszym, zerowym sprincie, czy na początku i cały czas już według tych wytycznych podążać. My się po prostu uczymy, to otoczenie technologiczne, biznesowe się zmienia, więc tak jak mówisz, to jest związane z tym długiem technologicznym.

Druga rzecz, o której powiedziałeś, to jest to, że ten dług technologiczny nam z czasem narasta, zwłaszcza jeśli go nie spłacamy, jeśli na bieżąco tego nie kontrolujemy, to w pewnym momencie możemy przejść już tę magiczną linię, za którą albo nie będzie miało zupełnie sensu tego długu spłacać, albo to będzie wręcz niemożliwe.

To wszystko, co ty powiedziałeś, co ja trochę dopowiedziałem, może stawiać ten dług technologiczny w takim obrazie bardzo pejoratywnym, że to jednak jest coś bardzo, bardzo złego. Mówiliśmy tutaj nawet o zgniliźnie, więc to jest powiązanie bardzo jasne. Ale właśnie — czy zawsze dług technologiczny jest problemem? I komu on zagraża w projekcie?

Można powiedzieć, że on zawsze jest problemem, tylko jego skutki nie zawsze są widoczne. Chodzi o to, że pewien poziom długu technologicznego nie jest groźny i nawet można powiedzieć, że sam jest wskazany, bo dzięki niemu jakoś tam rozwijamy tę naszą aplikację szybciej, ale czasami po prostu jak on się zbiera, nie ma takich natychmiastowych, oczywistych skutków, które informują nas o tym, że coś jest nie tak i warto by było z tym powalczyć.

Można by było powiedzieć, że zagraża developerom, ponieważ oni później muszą walczyć w tym środowisku o to, żeby jakoś tę aplikację rozwijać, ale ja bym powiedział, że on zagraża całemu otoczeniu i wszystkim, którzy mają jakąkolwiek styczność z tym oprogramowaniem, które jest zadłużone. Czyli developerom, którzy się męczą przy jego rozwoju, można powiedzieć, że biznesowi, ludziom albo w ogóle całej organizacji, jej finansom. W taki sposób, że nie dowozimy ficzerów na czas, nasza konkurencja rozwija się szybciej.

Może nawet wpływać na użytkowników, jeżeli mamy jakieś niestabilne oprogramowanie. Tutaj fajnym przykładem mogą być gry komputerowe. Często gry są np. rozwijane przez 10 czy 12 lat i jeśli ten dług się nawarstwi, to może się okazać, że nawet użytkownicy końcowi mają niezbyt przyjemne styczności z tym oprogramowaniem, bo np. ciężko jest rozwijać tę grę i jakieś aktualizacje wychodzą bardzo późno, gracze odchodzą.

Jasne. Mówiłeś tutaj o tym, że możemy ten dług technologiczny, powiedziałbym świadomie zaciągać. Dobrym przykładem może być startup, kiedy powstaje gdzieś jakieś MVP, takie trochę na kolanie robione.

W związku z tym chciałbym cię zapytać, kiedy ten dług technologiczny jest czymś naturalnym, a kiedy już staje się problemem?

Myślę, że tutaj nie ma takiej jednoznacznej granicy, trzeba samemu sobie ocenić, zadeklarować jakieś drivery, które o tym świadczą, ale myślę, że w skrócie można powiedzieć, że wtedy, kiedy zaczyna nam przeszkadzać. Spowalnia na przykład naszą pracę, spowalnia development, jest jakimś źródłem dużej ilości błędów albo np. oprogramowanie zaczyna nam się zachowywać w jakiś nieprzewidywalny sposób. Na przykład chcemy wpłynąć na jakąś określoną część aplikacji, rozwijamy ją, a zmienia się pięć innych i mamy takie side effecty, że modyfikacja jakiejś części kodu wpływa nam na inną i nie mamy nad tym kontroli. To są już takie znaki, które mogą świadczyć o tym, że coś jednak jest nie tak.

Może też wpływać na zadowolenie użytkowników bezpośrednio, czyli wiemy o tym, bo dostajemy feedback od użytkowników, którzy mówią nam, że aplikacja działa wolno albo mierzymy to w jakiś sposób, albo zgłaszają nam błędy.

Właśnie, to jest ciekawy wątek, bo zawsze kojarzymy ten dług technologiczny z czymś bardzo technologicznym, z taką powiedziałbym architekturą, która gdzieś tam na backendzie sobie leży i tam się ewentualnie coś złego może dziać. Ale czy każdy rodzaj długu technologicznego, według ciebie, musi być komunikowany gdzieś wyżej — do biznesu, do produktu, do użytkowników, jednym słowem mówiąc, czy jest taki jasny podział długu na coś bardzo backendowo-technicznego, który to obszar jest odpowiedzialnością developerów i inny rodzaj długu, który właśnie może dotykać użytkowników i o którym biznes powinien przynajmniej wiedzieć.

Ja jestem zwolennikiem takiej wyraźnej transparencji, więc uważam, że wszystko powinno być komunikowane przynajmniej biznesowi.

Natomiast jeśli chodzi o użytkowników, to tutaj bym się zastanowił, dlatego że komunikowanie niektórych rzeczy może wpływać negatywnie np. na naszą markę. Bo jeżeli wyślemy komunikat do użytkowników: „słuchajcie, oprogramowanie nam się wali, mamy niesamowitą ilość długu technicznego”, to to może źle na nas wpłynąć. Ale jeżeli są jakieś elementy, które mogą podbudować tych naszych użytkowników, utrzymać ich trochę przy naszej aplikacji, np. jeżeli powiemy im: „słuchajcie, mamy drobne problemy, ale jeżeli wy czekacie, to jesteśmy w stanie to naprawić”, to myślę, że warto to zakomunikować.

Jedynie gdzie bym się zastanawiał, to sytuacja, gdy mamy jakiś dług, który jest taki marginalny, nieznaczny. Myślę tu o czymś takim, że jeżeli jest to dług w kodzie, to możemy go rozwiązać, zostawiając to do’s-a i ktoś, wchodząc do tego pliku następnym razem, po prostu to zrobi. Myślę, że takie rzeczy ewentualnie można by było pominąć. Ale tak poza tym, to ja jestem zdania, że dobrze jest komunikować, ponieważ jeżeli biznes jest świadomy tego długu, to później można to zaplanować w jakimkolwiek frameworku pracujemy.

Chciałbym jeszcze pociągnąć trochę ten wątek świadomości, bo my jako osoby techniczne, związane z IT, wiemy mniej więcej jaki jest impact, jaki jest wpływ tego długu technicznego taki krótkoterminowy, ale też długoterminowy. Wiemy, jaka jest waga, wiemy, jak ten dług zaciągamy i co będziemy musieli spłacać.

Ale dla biznesu, zwłaszcza tego nieświadomego, to może być coś bardzo oderwanego od tej biznesowej domeny, coś, co jest ciężkie w zrozumieniu. Coś, co bardzo trudno jest przeliczyć na pieniądze, czy też inwestycja w ten obszar byłaby trudna do przeliczenia na pieniądze, w związku z tym może to być taki obszar trochę ignorowany. Dlatego chciałbym zapytać, czy znasz jakieś sposoby tłumaczenia osobom nietechnicznym, jaka jest rola długu technicznego, jak można nim zarządzać, jak można go spłacać?

Jeszcze nawiążę do tego, że my rozumiemy impact tego, a niekoniecznie możemy być w stanie przełożyć to na pieniądze, straty, zyski, czy coś takiego — tak, jak najbardziej. I myślę, że skoro my jesteśmy inżynierami, specjalistami, architektami, to wydaje mi się, że to naszym zadaniem jest przyłożenie do tego odpowiedniej wagi. Można nawet powiedzieć, że my, jako zespół developerski albo programiści, architekci, inżynierowie jesteśmy takim stakeholderem jakości artefaktów naszego oprogramowania, więc wydaje mi się, że w naszym obowiązku jest wytłumaczenie tego biznesowi. Tak, jak tłumaczymy różne inne rzeczy związane z oprogramowaniem, np. że jest jakiś problem z danymi, incydenty, GDPR itd. Takie rzeczy się tłumaczy, wydaje mi się, że na porządku dziennym.

I też postawmy się na miejscu drugiej strony — w momencie, kiedy pracujemy nad skomplikowaną domeną, niech będzie to źródło energii odnawialnej, to ten biznes, który tak bardzo nie rozumie tego naszego długu technologicznego, on też ma problem, żeby wytłumaczyć nam swoją domenę, w której operuje. Na przykład pojawiają się jakieś terminologie związane z urzędami rejestrującymi różnego rodzaju jakieś inwertery energetyczne. Oni też muszą nam to wytłumaczyć, nie mogą nas zignorować, więc my też nie ignorujmy ich. Starajmy się to im wytłumaczyć, używajmy różnego rodzaju metafor, jak np. finansowych.

Kiedyś usłyszałem taką bardzo fajną metaforę od koleżanki z Boldare, która mówi, że dług technologiczny jest trochę jak gotowanie — jeśli chcesz sobie ugotować obiad, przygotowując go, kroisz marchewki itd., zostaje ci potem brudny blat, jakieś obierki itp. I to jest ten twój dług, który musisz posprzątać, zanim zaczniesz ponownie gotować, bo jak go nie posprzątasz, to wiadomo, co się stanie.

I też postawmy się na miejscu drugiej strony — w momencie, kiedy pracujemy nad skomplikowaną domeną, niech będzie to źródło energii odnawialnej, to ten biznes, który tak bardzo nie rozumie tego naszego długu technologicznego, on też ma problem, żeby wytłumaczyć nam swoją domenę, w której operuje. Na przykład pojawiają się jakieś terminologie związane z urzędami rejestrującymi różnego rodzaju jakieś inwertery energetyczne. Oni też muszą nam to wytłumaczyć, nie mogą nas zignorować, więc my też nie ignorujmy ich. Starajmy się to im wytłumaczyć, używajmy różnego rodzaju metafor, jak np. finansowych.

Bardzo obrazowe, ale faktycznie może docierać.

Muszę przyznać, że bardzo podoba mi się twoja odpowiedź, czyli po prostu nastawienie na komunikację i na obustronne zrozumienie. Nie stawianie siebie w takim obozie, który mówi: „ja to rozumiem, a to wy nie rozumiecie”, tylko raczej próba dogadania się, próba wzajemnego zrozumienia, która jest pewnie jedynym i najbardziej skutecznym sposobem, żeby jakoś wychodzić z tego długu technicznego, który powstaje na co dzień, nieraz niezależnie od tego, co byśmy zrobili. Bo trzeba też sobie jasno powiedzieć, że bardzo trudno jest znaleźć takie rozwiązania w IT też w software developmencie, które są wolne od długu technicznego. To jest najczęściej jakiś rodzaj zrezygnowania z czegoś na korzyść czegoś innego, ale wiadomo — musimy iść na jakieś kompromisy.

Dokładnie.

Jeśli chodzi o to, czy jesteśmy świadomi tego długu technicznego albo czy w ogóle wiemy, że go mamy, to możemy się o tym przekonać, dostając bardzo niemiłą informację, że faktycznie mamy jakiś dług techniczny, bo coś np. przestaje działać. Może się okazać, że biznes czy produkt zwraca się do nas, że np. szybkość developmentu nam ostatnio mocno spada albo estymując jakieś kolejne rzeczy, wychodzimy na coraz większe czasy, bo zarządzanie tym długiem niestety stanowi dodatkową pracę.

W związku z tym dążę do tego, że dobrze by było ten dług techniczny jakoś mierzyć, żeby być świadomym, ile go mamy i później jakoś nim zarządzić. Czy jest coś, co według Ciebie daje nam taką możliwość mierzenia długu technicznego? Jakieś metody, jakieś narzędzia, może jakieś podejścia?

Taką żartobliwą miarą może być coś, co widziałem kiedyś w memie — „dług techniczny można zmierzyć, dając developerowi kod do przeczytania i słuchając ile razy poleci WTF z perminent. To może być jedna z miar. Oczywiście to jest żart, ale…

Tak jak KPI.

Tak, dokładnie — tak, jak KPI.

Myślę, że narzędzi jest sporo. Możemy mierzyć jakąś złożoność cyklomatyczną naszego kodu, jakąś złożoność poznawczą, łącząc to z jakimiś prostszymi metrykami, jak chociażby pokrycie kodu, to, jakie mamy przedawnione biblioteki, ile mamy jakichś security vulnerabilities, podatności, ile mamy bugów — to są takie rzeczy, które można mierzyć.

Z takich bardziej nieoczywistych może, to możemy mierzyć, może niekoniecznie czas w minutach, ale ile nam zajmuje onboarding nowego developera. Bo to, że nowy developer nie jest w stanie w miarę szybko wejść w nowy projekt, świadczy o tym, że czegoś w nim brakuje — dokumentacji czy po prostu ciężko zrozumieć domenę, przeczytać co siedzi w tym kodzie.

Możemy też korzystać z jakichś bardziej zaawansowanych technik, które stawiają już na liczby, jak np. Technical Debt Ratio czy SQALE, czyli Software Quality Assessment based on Lifecycle Expectations. I to są metryki, które może mierzyć nam np. narzędzie SonarQube. SQALE właściwie można powiedzieć, że opiera się na tym samym, co wymieniłem przed chwilą, czyli testowalności kodu, readability, jak bardzo jest podatny na zmiany, jaki ma performance, czy jest bezpieczny, czy jest utrzymywalny, czy łatwo go portować na inne środowiska, czy np. kod jest reużywalny, mierzy, ile razy pojawia się duplikacja kodu, znajduje jakieś codes smellsy i na podstawie tego może, że tak powiem, wypluć nam jakiś wynik, jaki jest poziom naszego długu technicznego.

Myślę, że warto to mierzyć, ale to są już takie rzeczy, że myślę, że ustawienie tego w swoim procesie zajmuje dużo czasu i to faktycznie będzie przydatne w projektach, które są duże, mają wiele zespołów, myślę, że setki ludzi na spokojnie.

Ja mam też takie podejście troszeczkę prostsze. Nie wiem, czy się ze mną zgodzisz, ale ja uważam je za obiektywne. Jeżeli zgodzisz się ze mną, że story pointy są miarą obiektywną, to zgodzisz się, że taka metoda też jest. Przeczytałem kiedyś o niej na blogu technicznym Riot Games, to jest game developer, który stworzył sławną grę League of Legends. Ich Engineering Manager napisał o tym, jak oni kategoryzują w ogóle dług technologiczny i jak sobie z nim radzą, jak go mierzą.

Wymienił coś takiego, że można skategoryzować, a właściwie nadać cechy długowi w postaci tego, jaki on ma impact, jaki on ma wpływ na organizację czy cokolwiek, jaki jest koszt jego naprawienia, czy spłacenia tego długu i jak bardzo jest on podatny na rozprzestrzenianie, tam jest użyty taki termin jak contagion — zaraźliwość. I wtedy jakiś określony fragment długu technologicznego, który znajdziemy w naszej aplikacji, jakiś po prostu code smell czy coś takiego, można ocenić w tych kategoriach na skali 1 do 5 albo na przykład w skali story pointów.

I w ten sposób mamy porównanie, które elementy naszego długu technologicznego są gorsze, które są lżejsze, a które może warto szybciej zaadresować. I to też pomaga nam priorytetyzować i mieć ogląd. Nie są to takie twarde, suche dane czy liczby mówiące, że u nas jest np. 5% długu technicznego, ale wydaje mi się, że to i tak jest spoko metoda, która jest znacznie prostsza i szybsza w implementacji niż postawienie np. SonarQube’a na całą organizację i zdefiniowanie wszystkich tych metryk.

Wymienił coś takiego, że można skategoryzować, a właściwie nadać cechy długowi w postaci tego, jaki on ma impact, jaki on ma wpływ na organizację czy cokolwiek, jaki jest koszt jego naprawienia, czy spłacenia tego długu i jak bardzo jest on podatny na rozprzestrzenianie, tam jest użyty taki termin jak contagion — zaraźliwość. I wtedy jakiś określony fragment długu technologicznego, który znajdziemy w naszej aplikacji, jakiś po prostu code smell czy coś takiego, można ocenić w tych kategoriach na skali 1 do 5 albo na przykład w skali story pointów.

Pewnie. Ja myślę, że obojętnie jakiej metody byśmy tutaj nie wzięli, to i tak będzie lepiej, niż gdybyśmy w ogóle nie brali żadnej. W sensie jakakolwiek forma mierzenia jaki ten dług techniczny jest, jest lepsza niż żadna.

Podoba mi się to, co powiedziałeś, że niektóre z tych narzędzi, jak np. te związane z coveragem czy z analizą statyczną, da się jakoś nawet włączyć w proces CI/CD i mieć ten feedback tak w miarę na bieżąco.

Zgodzę się też absolutnie z tym, że patrzenie, jak nam spada ta szybkość developmentu to też jest jakiś objaw faktycznie długu technicznego. Jeśli się okaże, że mamy coraz więcej bugów, coraz więcej jakichś ticksów związanych z security, z podbijaniem paczek itd., no to faktycznie jest to jakiś obraz tego, że ten dług techniczny rośnie.

To, co ja teraz nieraz też robię w projektach, to jest taka próba spisywania sobie mniej więcej ile developer, szacunkowo oczywiście, poświęca w ciągu dnia czasu np. na nowe ficzery, na bugi, fixy, związane z bezpieczeństwem, podbijanie paczek itd. Jak się na to spojrzy, nawet jeśli jest bardzo ogólnie zrobione, to od razu widać w czasie, jak to się zmienia i widać też, że jeśli w miarę na bieżąco się tego długu technicznego, przynajmniej tego związanego z takim mocnym impactem na biznes, nie próbuje łatać, to to się akumuluje w czasie i później faktycznie ta szybkość developmentu nam spada.

Dokładnie. Można też zawsze, choć może to nie jest już takie obiektywne, ale zwyczajnie popatrzeć — jeżeli pracujecie w jakichś zwinnych oczywiście frameworkach, jak nie wiem, Scrum na przykład — historycznie, np. jaka była średnia wysokość takiego przeciętnego ficzera, storiesa w story pointach i porównać ją np. dzisiaj. Co było pół roku temu, a co było dzisiaj.

Oczywiście to może odbiegać od realiów, bo np. teraz możemy po prostu robić grubsze rzeczy, niż wtedy, ale można mniej więcej, tak poznawczo spróbować porównać, takie powiedzmy, średnie rzeczy pół roku temu, a średnie rzeczy teraz i zobaczysz, że np. estymata jest znacznie wyższa — to znaczy, że roboty jest tyle samo, ale złożoność tego jest większa, trudniej jest to po prostu wprowadzić, wdrożyć.

Dokładnie. Na podobny powiedzmy ficzer, musimy poświęcić więcej czasu, żeby go finalnie dowieźć, dokładnie tak.

Ok, powiedzieliśmy trochę o mierzeniu długu technicznego. Dług techniczny można też dokumentować. Z racji tego, że często jest on związany z jakimiś decyzjami, które podejmujemy, idziemy w tym kierunku, a nie w tamtym, w związku z tym świadomie albo nieświadomie zaciągamy jakiś dług. Jeśli jesteśmy w miarę tego świadomi, to możemy to jakoś udokumentować. Decydujemy się np. na taki framework, taką bibliotekę, cokolwiek i w związku z tym wygeneruje to taki, a nie inny efekt.

Wydaje mi się, że dokumentowanie długu technicznego jest też istotne w momencie, kiedy trafiamy na jakiś projekt, już taki np. wieloletni i tam niczego takiego nie ma i tak naprawdę nie ma też testów, co też oczywiście się zdarza, nie wiemy, gdzie jesteśmy, w związku z tym musimy przynajmniej go dokumentować, ten punkt startowy.

Chciałbym cię zapytać o twoje doświadczenia, twoje opinie, twoje zdanie na temat właśnie dokumentowania długu technicznego — czy to w ogóle warto ? Jeśli tak, to może, w jaki sposób?

Nie jestem wielkim fanem dokumentowania. Powiedziałbym, że jestem raczej przeciwnikiem, ale tutaj muszę się zgodzić z tym, że warto to robić, bo to wspomaga tę wcześniej wspomnianą transparencję. Ja na przykład robię to w postaci, chociażby wpisywania tego do backlogu tak naprawdę. Wrzucanie elementów spłaty długu technicznego do backlogu — w ten sposób biznes o tym wie, product owner, chociażby o tym wie. Można to jakoś trackować, priorytetyzować, dzięki temu nie zapomina się o tym przede wszystkim.

Druga opcja to jest wiadomo, to do’s-y w kodzie — bardzo w porządku. Albo jakieś informacje o tym, że coś zostało deprecated — to wszystko jest w porządku, na zasadzie wrzucamy to do’s-a i mówimy: „to powinno zostać usunięte po tym releasie, bo już ta część kodu nie będzie nigdy używana albo coś tam”.

I kolejna rzecz, związana z decyzjami, o których mówiłeś. Tutaj wydaje mi się, że świetnie sprawdzają się ADRy — Architecture Decision Record, gdzie jeżeli podejmujemy jakąś decyzję pójścia na skróty, możemy to udokumentować, napisać od razu, jaka byłaby opcja alternatywna, która kosztuje nas więcej, zajmuje więcej czasu. Możemy podać, co nami kierowało w wyborze tej decyzji, wtedy ktoś, kto np. wpadnie do projektu, będzie wiedział, jaka była jego historia, dlaczego taka decyzja została podjęta, co było rozważane innego i tak naprawdę na podstawie tego może sobie wnioskować albo po prostu wymyślać co dalej z tym zrobić.

I kolejna rzecz, związana z decyzjami, o których mówiłeś. Tutaj wydaje mi się, że świetnie sprawdzają się ADRy — Architecture Decision Record, gdzie jeżeli podejmujemy jakąś decyzję pójścia na skróty, możemy to udokumentować, napisać od razu, jaka byłaby opcja alternatywna, która kosztuje nas więcej, zajmuje więcej czasu. Możemy podać, co nami kierowało w wyborze tej decyzji, wtedy ktoś, kto np. wpadnie do projektu, będzie wiedział, jaka była jego historia, dlaczego taka decyzja została podjęta, co było rozważane innego i tak naprawdę na podstawie tego może sobie wnioskować albo po prostu wymyślać co dalej z tym zrobić.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-130-dlug-technologiczny/

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.