Technologický dlh je niečo, čo môže zmeniť utešený projekt na nočnú moru. Bohužiaľ ale nenosí tabuľku s nápisom, a tak sa môže stať, že sa stane vaším spoločníkom v projekte skôr, ako si niečo všimnete. Ako  sa tam dostal, ako ho rozpoznať a čo s tým robiť? Stalo sa vám niekedy, že sa spočiatku bezproblémová práca na projekte začala podobať na plávanie v hustom sirupe. Že každý pohyb, každá zmena vás stála veľa námahy a nič nebolo také jednoduché, ako sa to zdalo. Alebo ste mali pocit, že ste uviazli v pavučine a každý váš pohyb (zmena kódu) rozhýbe časti aplikácie, o ktorých ste boli presvedčení, že s tým, čo robíte, nesúvisia. Jeden z dôvodov, prečo sa inak zábavná a inšpiratívna disciplína ako je programovanie môže zmeniť v takúto nočnú moru je niečo, čo sa zvykne označovať technologický dlh.

Technologický dlh, zoznámte sa

Najjednoduchšia definícia technologického dlhu pravdepodobne je, že je to práca, ktorá mala a nebola a vykonaná. To znamená, že ste tomu softvérovému riešeniu ostali niečo dlžní. Zjednodušene sa dá povedať, že technologický dlh môže rásť dvoma spôsobmi: vedomím a nevedomím.

Prvý, vedomý ste už možno niekedy zažili. Je to vtedy, keď ste sa rozhodli vykonať nejakú (hoci aj malú) skratku v kóde a porušiť tak dohodnuté pravidlá. Alebo keď ste vedeli, že by bolo dobré upratať kód, ale neurobili ste to. Keď ste prijali nejaké riešenie s myšlienkou, že je to len na určité obdobie … a už ste sa k nemu nikdy nevrátili. Najčastejšie sa tak deje kvôli nedostatku času a občas aj kvôli nedostatku vôle (čomu sa menej diplomaticky zvykne hovoriť aj lenivosť). Pri tomto spôsobe narastania dlhu ho do systému vedome vkladáme. Hovoríme si: „Zatiaľ to nechám tak a neskôr to opravím/vyčistím/vyriešim.“ „Neskôr“ ale bohužial nie je žiadnym dňom v týždni, a tak dlh ostáva v systéme. Mimochodom, dočasné riešenie sa stáva trvalým akonáhle prežije bez zmeny nasledujúcu iteráciu, v ktorom bolo vytvorené. A „dočasné riešenie“ sa dá inak čítať ako „technologický dlh“.

Druhý, nevedomý spôsob súvisí s rozbíjaním okien. Možno ste už o tej analógii počuli. Predstavte si opustený dom uprostred mesta. Okná a dvere sú zatvorené, vo vnútri sa nič nehýbe. Budova tak môže stať celé roky a nič sa nedeje. Až do momentu, keď niekto rozbije prvé okno a ujde. Rozbité okno, ktoré nikto neopraví je podvedomý signál pre všetkých, že o budovu sa nikto nestará, a tak sa v krátkom čase objavia nasprejované nápisy, niekto rozbije ďalšie okná a nakoniec vylomí dvere. Z pôvodne normálne vyzerajúcej budovy je zrazu ruina. A všetko to začalo rozbité okno. Niečo podobné sa môže stať aj vášmu softvéru. Ak meníte kód, v ktorom sú jasne dodržané pravidlá, bude vás to podvedome nútiť, aby ste ich dodržiavali aj vy. Ale keď si všimnete, že nie všetky premenné sú pomenované podľa dohodnutých konvencií alebo že niekde je použitý odkaz priamo na triedu aj keď dohoda bola používať rozhrania, bude vás to skôr viesť k ich porušovaniu. A to je spôsob, ako sa do vášho systému začne dostávať technologický dlh. Ak boli na začiatku všetky triedy fit, tak po niekoľkých rozbitých oknách a nejakom čase ďalšieho vývoja, už to nemusí byť také jasné. Systém pod rukami pomaly degraduje a mení sa na ruinu, ale tie krôčiky sú také malé, že to vôbec nemusí udrieť do očí.

Ako poznám, koľko som dlžný?

Ako sa dá prítomnosť dlhu rozpoznať? Technologický dlh nesúvisí priamo s behom systému, aj keď dokáže ovplyvniť aj to. Súvisí hlavne so zmenami a udržiavaním (spravovaním) systému a jeho stabilitou. Nečakajte, že ho jedného dňa nájdete niekde v nejakom súbore. Väčšinou nie je zďaleka takto viditeľný. Najlepší indikátor je ľahkosť (nekomplikovanosť) práce.

Ak sa technologický dlh objaví, začne to tým, že aj jednoduché veci sa začnú komplikovať a práca vas prestane baviť (to môže byť naozaj reálny ukazovateľ). Väčšiu časť času začínate tráviť detektívnou prácou pri hľadaní odpovede na otázku, prečo je to urobené tak, ako to urobené je (či je to naschvál alebo len niekto zabudol niečo po sebe upratať). Dostaví sa stres, pretože termíny sú termíny a vy tu pritom zápasite s nečakanými komplikáciami. Po strese prichádza strach. Je to strach zmeniť kód alebo konfiguráciu niečoho, keďže neviete, čo všetko tá zmena môže spôsobiť. Ak cítite strach pred zmenou, zašli ste už dosť ďaleko a ciest na návrať už nie je veľa (aj keď stále nejaké ostávajú). Posledným štádiom je kóma. To je stav, kedy už do systému radšej nevŕtate, pretože neviete, čo by sa stalo a koľko času by to bolo, dať to celé späť dokopy. Systém v kóme je už ťažko liečiteľný a najčastejšie sa už v tom čase píše druhý, nový, ktorý by mal ten pôvodný nahradiť.

Nechcem byť dlžný, čo s tým?

Už vieme, čo technologický dlh je, ako vzniká a ako sa prejavuje. Ostáva len otázka, ako s ním zápasiť. Nástrojov a postupov je niekoľko. Pri vedome vytváranom dlhu je najlepšie sa vyhnúť kompromisom a snažiť sa o technicky zdatné riešenie na prvýkrát. Niekedy sa to nedá a niekedy je dokonca nedokonalé riešenie žiadané. Napríklad pri agilných metódach môžete v jednej iterácii vytvoriť funkcionalitu za krátky čas jednoduchším spôsobom, aby ste ju vedeli zákazníkovi predviesť a ak mu bude vyhovovať, opraviť ju do korektného stavu. V takom prípade ale ak príde A, musí prísť aj B. Ak ste takéto nedokonalé riešenie do systému dostali, musíte ho opraviť alebo zo systému vyhodiť. Samozrejme, že to znamená prácu naviac a komunikáciu so zákazníkom, prečo treba niečo prerábať (refaktorovať), ak to funguje. Ale aj o tom vývoj softvéru je. Dobrou pomôckou je zoznam takýchto dočasných riešení umiestnený na nejakom dobre viditeľnom mieste. Takto sa len veľmi ťažko dá zabudnúť na to, čo je ešte potrebné spraviť.

Nevedomé vytváranie dlhu najlepšie zastavia nástroje na kontrolu pravidiel. Ide o rôzne nástroje na statickú alebo dynamickú kontrolu kódu (napríklad FxCop pre .Net alebo Checkstyle pre Javu). Samotný nástroj o sebe nestačí, niekto ho musí spustiť a vyhodnotiť. Ten niekto by to mal robiť automaticky a nemal by na to zabudnúť. Nič lepšie ako kontinuálne zostavovanie ma nenapadá (napríklad CruiseControl). Najlepšie hneď po zmenách v kóde, aby doba medzi zavedením chyby a jej odhalením bola čo najkratšia. Takýto správne nastavený systém vie udržať váš kód vo forme aj dlhú dobu. Automatika však nie je všetko, preto aj CodeReview, teda kontrola kódu jedného vývojára druhým, prináša svoje (osobitné) výsledky.

Samostatnou kapitolou je zápas s technologickým dlhom, ktorý sa začne až niekde uprostred projektu (niekedy aj po niekoľkých rokoch). V takom prípade treba v prvom rade zastaviť krvácanie, čo znamená urobiť všetko preto, aby dlh už nenarastal a identifikovať najboľavejšie miesta. To sú miesta, ktoré vás stoja najviac energie. A tie postupne odstraňovať.

Technologický dlh je prirodzeným dôsledkom okolností, ktoré projekt sprevádzajú a ľudskej nedôslednosti, ktorá sa občas vyskytne. Aj preto to nie je niečo, čo viete na 100% potlačiť. Dôležité je však, aby ste o ňom vedeli a snažili sa ho držať pod kontrolou, pretože je to spoločník, ktorý vám nebadane môže prerásť cez hlavu.