Už je to pekných pár rokov, čo vznikol článok Technologický dlh a prečo to nie je jedno. V ňom som napísal, že technologický dlhý vzniká vtedy, ak softvérovému riešeniu ostanete niečo dlžní. Jednoducho neurobíte nejakú robotu, ktorú ste mali. A robota (ako je všeobecne známe) sa sama neurobí. Odvtedy pretieklo veľa vody a ja som videl veľa projektov, veľa tímov a veľa riadkov kódu. A zistil som jednu vec, a to že tých druhov prác, ktoré nemusia byť urobené, je veľa. A preto je aj veľa druhov technologického dlhu. Častokrát je pritom tak maskovaný, že je ho ťažké rozpoznať.

Existuje jeden indikátor, ktorý vám prezradí, že váš projekt ma nejakú mieru technologického dlhu. Taký dlh totiž zaručene spôsobuje to, že aj malé zmeny trvajú dlho a sú rizikové. A to hovorím o naozaj jednoduchých veciach ako pridať pole do formulára a následne do serverovej časti aplikácie. Alebo urobiť pre projekt tak samozrejmú vec ako je release novej verzie.

Len si to predstavte, idete releasovať svoj softvér. A ocitáte sa v situácii, že to nikdy nevyjde na prvýkrát. Vlastne ani na druhý. Stále sa pripletú nejaké problémy. Raz zo zvláštnych dôvodov spadne proces zostavenia. Inokedy je niečo zle zamergované. Vždy sa niečo prihodí, niektoré problémy sa opakujú, ale vždy sa objavia nové. Stále sú to maličkosti, ale systém je taký krehký, že stačí aj málo a niečo prestane fungovať. A niekedy trvá dlho dopátrať sa k tomu, čo sa stalo.

Ak má váš projekt problémy, ktoré sa veľmi ťažko opisujú, ktoré nemajú jasný prejav a vinníka, len sa náhodne objavujú, je pravdepodobné, že sa v ňom niekde ukrýva technologický dlh. Poďme sa teda pozrieť na to, ako ten dlh môže vyzerať:

Rozpadnutá architektúra – hneď prvá forma je postupná premena niečoho, čo na začiatku bola architektúra (teda súbor pravidiel o štruktúre kódu) na špagetový kód (teda anarchiu). Pravidlá je potrebné časom samozrejme meniť, ale stále by mala byť jasná množina platná pre celý projekt. Ak má každý developer svoju vlastnú množinu, je to cesta do softvérového pekla. Iný problém je, ak nie je čas na činnosť nevyhnutnú pre dlhodobý projekt – refactoring. Ak sa totiž požiadavky na softvér menia, ale architektúra ostáva rovnaká, dochádza k pnutiu medzi tým, čo by ten softvér mal robiť a na čo je stavaný.

Zdivočelý kód – okrem architektúry, ktorá určuje čo kde patrí, je tu ešte štýl písania kódu. To je systém pomenovania funkcií, premenných, spôsob formátovania kódu a pod. Hovorí sa, že keď chcete vedieť ako funguje tím, pozrite sa na jeho kód. Ak každá trieda vyzerá inak, potom je niekde problém. Každopádne meniť takýto kód je všetko, len nie ľahké.

Neporiadok – kód, ktorý nikto nevolá. Konfiguračné súbory, ktoré sa už nepoužívajú. Kópie častí kódu, na ktorých ktosi v minulosti robil pokus (neúspešný), ale neupratal po sebe. A tak podobne. Neporiadok pravidelne spotrebováva obrovské množstvo vášho času a energie, keďže často sa tvári ako podstatná a používaná vec. Vám potom chvíľu trvá, kým pochopíte, že je to len zbytočnosť, ktorá zavadzia.

Chýbajúca dokumentácia a komentáre – obľúbený technologický dlh na množstve projektov. Častokrát aj s dôvetkom – my robíme agile, preto nedokumentujeme. Príčin je veľa, ale neochota manažmentu platiť čas na dokumentáciu a developerov ju písať, sú dve najčastejšie (a často dochádza ku kombinácii týchto príčin). Každopádne to vedie k tomu, že ľudia sú „nenahraditeľní“, keďže sú jediní, ktorí kódu rozumejú. Druhý aspekt je ten, že ak začnete dokumentovať to, čo ste vytvorili – začnete formulovať vety a myšlienky a vo vašom výtvore objavíte perspektívy, ktoré ste predtým nevideli. A možno nájdete chybu alebo zistíte, že niečo treba urobiť inak. Mne sa už veľakrát stalo, že pri opise funkcionality ma napadol okrajový stav, ktorý nebol ošetrený.

Chýbajúci ľudia a ich know-how – ak sa nedokumentuje, skôr alebo neskôr príde ďalšia forma dlhu – ľudia, ktorí to majú všetko v hlave, odídu a s nimi aj ich know-how. Čo vám po nich ostane sú zdrojové kódy a vy si môžete navariť veľkú šálku kávy a začať študovať (samotný kód, komentáre tam nie sú, viď. predchádzajúci dlh). Z kódu sa dá pri troche snahy vyčítať veľa, ale nikdy v ňom nenájdete odpoveď na jednu otázku – prečo? Prečo sa zvolilo dané riešenie. To autor buď niekde napísal alebo nie. A ak nie, tak vás ostáva už len hádať, alebo kód zmeniť a sledovať, čo sa bude diať (kto ale bude mať tú odvahu?).

Snowflake servers – servre, ktoré sú spravované všetkými a zároveň nikým. Či ide o infraštruktúru devopsu, testovacie alebo produkčné servre,  je to jedno. Funguje to tak, že na server sa prihlási niekto z tímu, niečo zmení, pretože potrebuje niečo otestovať alebo to jednoducho vyžaduje nová funkcionalita, ale nikomu nič nepovie. A „ideálne“ je, ak sa na server prihlasujú všetci pod tým istým – spoločným – účtom. Takže už vlastne nikto nevie, čo všetko kedy, kým a prečo bolo na serveri zmenené.

Chýbajúce testovanie – veľmi obľúbený technologický dlh, prezývaný tiež „tested by customer“. Testovanie ako investícia do kvality sa zákazníkovi strašne ťažko predáva, pretože ho nie je vidno. A keďže ho nie je vidno, tak ak ho neurobíte, nikto si to nevšimne. Preto, keď treba na projekte ušetriť, hádajte, čo ide ako prvé dole. K čomu to vedie asi netreba hovoriť. Vždy keď ide kvalita dole, treba posilniť hotline.

Vlastníctvo kódu – zvláštny druh dlhu, ktorý sa ale tiež často vyskytuje. Aby vývoj išiel čo najrýchlejšie, ten istý kód stále upravujú tí istí ľudia. Nerobí sa review a vlastníctvo nerotuje, lebo nový človek na novom kóde by sa musel zaučiť, a to stojí čas a čas nie je alebo peniaze nie sú. Výsledok? Dotyčný človek odíde na dovolenku a firma má problém. Alebo odíde a firma má ešte väčší problém.

Chýbajúca alebo nefunkčná automatizácia – toto je hlavne problém veľkých a dlhotrvajúcich projektov. V každom takomto projekt sa jednoducho vyskytuje nejaké množstvo rutinnej práce. Je nutné ho preniesť do skriptov a nástrojov na to určených. V opačnom prípade, ak to budú vykonávať dookola ľudia, je len otázka času, kedy začnú robiť chyby.

Ani tento zoznam nie je vyčerpávajúci a existujú ďalšie formy, možno trochu exotickejšie. Dôležité je pochopiť, že technologický dlh nie je niečo, čo vám jedného dňa zaklope na dvere, predstaví sa a vojde dnu. Vždy príde postupne a vždy vo forme, ktoré nie je zrejmá. Hovorí sa, že nemôžete riadiť niečo, čo  nemeriate. Z toho vyplýva, že by mali existovať metriky, ktoré na projekte viete sledovať, a ktoré vám napovedia, že k vám na projekt nastúpil nepozvaný pasažier. Napríklad počet chýb v produkcii, komplexnosť kódu alebo jednoducho neschopnosť jednoducho vytvoriť release. Všetko sú to nepriame indikátory, ale svojmu účelu môžu poslúžiť.

Steven Pinker vo svojej knihe Buď svetlo napísal, že podstatou ľudskej činnosti je neustály boj proti entropii, ktorá je pre náš svet vlastná. Že ak sa nebudete starať o svoj dom alebo záhradu, tak sa rozpadne a spustne. Lebo entropia je prirodzená sila, ktorá pôsobí na všetko a všetkých, a len ľudský um jej dokáže vzdorovať a veciam dať svoje miesto. V procese vývoja softvéru je technologický dlh tou entropiou. Je to chýbajúci poriadok, domáca úloha, ktorú si mali vývojári spraviť, ale neurobili. Nikto z nás by sa nechcel nasťahovať do rozpadajúceho sa domu, tak ako je možné, že sa tak často toleruje podobný stav v softvérových projektoch? Možno je to tým, že ešte potrebujeme lepšie porozumieť, čo to technologický dlh, ako sa prejavuje a prečo je nebezpečný.