Technický dluh a jeho dopady na kvalitu softwaru

Technický dluh je metafora, která vystihuje častý jev, vznikající při tvorbě softwarových systémů✱. Tento jev má téměř vždy negativní dopady a vyskytuje se v různých částech systému, z různých důvodů. Tento článek obsahuje definici technického dluhu, popisuje jeho vlastnosti a určuje několik různých druhů. Dále jsou popsány časté důvody vzniku technického dluhu a jeho přímé i nepřímé dopady na kvalitu softwaru. Nakonec jsou popsány postupy, jak technickému dluhu čelit.

✱ Pojmy software, systém a projekt jsou používány zaměnitelně pro označení celku, na jehož tvorbě se podílí skupina lidí (tým vývojářů, management, zákazníci).

Pojem technický dluh poprvé použil Ward Cunningham jako metaforu, která se týká vývoje softwaru.

Cunningham uvádí, že aby bylo dosaženo největší kvality softwaru, musí být implementace průběžně konsolidována (musí se odstraňovat nedostatky a zvyšovat její logická soudržnost). Počáteční implementace sice může být ze začátku pro zákazníka přijatelná, ale pokud nebude prováděn pravidelný refactoring, může to ohrozit celou organizaci:

Ward později upřesňuje, že tato metafora neznamená vytvoření špatné implementace a jejího pozdějšího upravení na lepší implementaci. Spíše jde o vytvoření takové implementace, která odpovídá úrovni poznání dané domény a její postupné zlepšování s tím, jak poznání roste. Technický dluh podle něj také neznamená odložení implementace funkcionality. Týká se jen technických rozhodnutí, která ovlivňují další vývoj.

Na rozdíl od Cunninghama, ostatní autoři do svých definicí zahrnují i nedokonalosti implementace. Steve McConnell dělí technický dluh podle následující taxonomie (viz toto video pro podrobný popis):

Úmyslný dluh vzniká v systému přijetím explicitního rozhodnutí, které má své důvody a může sloužit vyššímu cíli. Neočekávaný dluh naopak vznikne aniž by to někdo pozoroval a později způsobuje nečekané komplikace.

Krátkodobý dluh je takový, u kterého se očekává, že bude splácen často (např. mezi jednotlivými vývojovými cykly) nebo průběžně. Dlouhodobý je naopak v systému delší dobu.

Podobně jako McConnell, i Martin Fowler ve svém příspěvku zahrnuje neúmyslné nedokonalosti implementace do technického dluhu. Navíc rozlišuje, zda byl dluh přijat z dobrého důvodu, či nikoliv, pomocí následující matice:

První kvadrant označuje technický dluh, který byl přijat za účelem splnění nějakého cíle s plným uvědoměním si následků - ”Software musí být vydán hned. Uvědomujeme si, jak to ovlivní další práci”.

Druhý kvadrant označuje dluh, který byl přijat záměrně, ale toto rozhodnutí nebylo promyšleno a nemá dobrý důvod - ”S designem se teď nebudeme zdržovat”.

Do třetího kvadrantu spadají případy, kdy vývojáři nevědí, že přijímají technický dluh nejčastěji kvůli vlastní neschopnosti - ”Nějak to tam nasekáme”.

Do posledního kvadrantu patří případy, kdy vývojáři sice udělali neoptimální rozhodnutí, ale později je odhalili a byli schopni se z nich poučit - ”Teď už víme, jak na to”.

Dále v tomto článku budeme pracovat s touto definicí:

Často jsou rozlišovány různé typy technického dluhu podle toho, která část systému ho obsahuje.

Metafora technického dluhu se postupně vyvíjela a vznikaly další paralely s finančním dluhem. C. Seyman a Y. Guo ve své akademické práci formalizují pojmy, které jsou často ve spojení s technickým dluhem používány.

Tyto míry nelze měřit přesně a musí se odhadovat. Přesnost těchto odhadů bude záviset na zkušenosti osoby, která bude odhady provádět a také na dostupných historických datech. Čím jsou dostupná data podrobnější, tím přesnější budou odhady. Zřejmě nejtěžší bude odhad výše úroků, protože vývojáři jen těžko vezmou v potaz všechny možnosti, jak je může technický dluh ovlivnit.

Přirozeným důvodem vzniku technického dluhu, tak jak jej definoval Cunningham je nedostatečná znalost problematiky ze strany vývojářů, zejména v počátečních stádiích vývoje.

Častým důvodem jsou také vnější faktory, které vyvíjejí tlak na vývojáře, aby zrychlili dokončení projektu nebo implementaci funkcionality. Takovým faktorem může být (technický) management, změna požadavků zákazníka (a to i v konečné fázi implementace) nebo změna různých vnějších podmínek (tržní, legislativa). Časový skluz způsobují i nesprávné odhady (zejména od třetích stran, které se přímo nepodílí na vývoji), které neobsahují rezervy, nebo byly jednoduše vytvořeny nezkušenou osobou.

Vývojáři nejsou nezávislí na zbytku organizace, musejí přinášet užitek naplňováním business požadavků, které jsou navíc často závislé na čase (daná vlastnost softwarového produktu přinese zisk nyní, ale už ne později). Často se proto musejí podřídit a přistoupit na kompromisy.

Různé typy technického dluhu vznikají v různých částech systémů z různých důvodů. Pokud vývojáři nejsou dostatečně kompetentní, vzniká technický dluh všude, navíc aniž by o něm někdo měl ponětí.

Dluh zdrojového kódu vzniká pokud v týmu nejsou nastavena určitá pravidla o tom, jak by měl být kód napsán. Pro tyto účely vznikají v týmech stylistické manuály a jsou používány automatické nástroje pro úpravu kódu (tzv. lintery).

Testovací dluh vzniká, když je napsání testů odděleno od implementace funkcionality, tedy pokud jsou testy napsány někým jiným, nebo v pozdějším vývojovém cyklu.

Vznik technického dluhu není vždy nežádoucí. Mohou nastat situace, kdy je možné obhájit zadlužení. Obecně půjde o případy kdy je výhodnější dokončit projekt dříve a potřebné úpravy či refactoring provést později (náklady na tyto budoucí změny jsou menší, než případný ušlý zisk, pokud nebude projekt či funkcionalita dokončena včas). Pokud je kritické vstoupit na trh co nejdříve, bude pro organizaci lepší nashromáždit technický dluh, než promarnit příležitost.

Technický dluh není viditelný pro zákazníky a často ani pro management, proto není překážkou k používání softwaru. Naopak, čím dříve zákazník začne software používat, tím dříve dostanou vývojáři zpětnou vazbu (toto je jedna ze zásad agilního vývoje). Avšak čím je větší, tím jsou změny nebo přidání nové funkcionality složitější. Někdy můžou být změny i nemožné. Vývoj se zpomaluje i přesto, že efektivita vývojářů je stejná jako předtím. Požadavky zákazníků nejsou naplňovány nebo nejsou naplňovány včas. Pokud není technický dluh ”splácen”, bude se neustále zvětšovat a může přerůst cenu, kterou je zákazník zaplatit.

Vývojáři jsou ti, kdo jako první pocítí dopady technického dluhu a to proto, že s ním přicházejí do styku každý den. Technický dluh ztěžuje jejich práci.

Špatně napsaný zdrojový kód, který nedodržuje konvence je obtížné číst a tím se ztěžuje jeho pochopení pro ty, kdo ho nevytvořili ale musí na něm provádět úpravy.

Pokud je architektura špatně zvolena, komponenty jsou nadměrně provázané a systém je příliš komplexní, je obtížné přidávat novou funkcionalitu a plnit požadavky zákazníků. Vývojáři nemají jistotu, že jakákoliv změna nezpůsobí obtížně nalezitelné defekty. Snižuje se stabilita celého systému.

Dopady technického dluhu budou vždy negativní (nikdy nebudou mít pozitivní vliv na kvalitu) ale jsou situace, kdy alternativa má ještě horší dopad. Vždy tedy půjde o volbu menšího zla. Je také zřejmé, že je pro organizaci nejvýhodnější snižovat technický dluh na minimum - splácet ho.

Software Design X-Rays je kniha, která se zabývá identifikací technického dluhu pomocí analýzy toho, jak vývojáři pracují.

Managing Software Debt se snaží o definitivní popis problematiky technického dluhu.

A Balancing Act: What Software Practitioners Have to Say about Technical Debt je studie zabývající se technickým dluhem, která byla vypracována z interview s odborníky z praxe.

Refactoring for software design smells: managing technical debt obsahuje popis 25 "code smells" a způsoby jak je refaktorovat za účelem snížení technického dluhu.