Technický dluh: Co to je, jak vzniká a jak ho efektivně řešit

Softwarový pojem „technický dluh“ byl poprvé zmíněn Wardem Cunninghamem v roce 1992, který jej definoval jako „kód, který není úplně správný“. Tato definice technického dluhu se používá dodnes, i když je pravdou, že byla rozšířena tak, aby zahrnovala všechny interní úkoly vývoje softwaru, které byly odloženy. Dnes tak popisuje dluh, který vzniká vývojovému týmu, když se rozhodne pro snadné nebo rychlé řešení za účelem dosažení krátkodobého výsledku. Tento dluh tak představuje budoucí náklady, které bude potřeba v budoucnu zaplatit i s úroky.

Kdy vzniká technický dluh?

Technický dluh obvykle vzniká v situaci, kdy si vývojový tým musí vybrat mezi zachováním standardů kvality systému a uvedením softwaru do provozu v co nejkratším čase a s využitím minimálních zdrojů. Jedná se tedy o situaci, kdy:

• jde čas proti vývojovému týmu, který je pod palbou termínů, které není schopen dodržet;
• má vývojářská společnost nedostatek finančních nebo lidských zdrojů;
• vývojáři nemají potřebné zkušenosti, v důsledku čehož se nevědomky dopouští zásadních chyb a generují tak technický dluh;
• se často mění původní návrh a požadavky zákazníků;
• vývojový tým používá zastaralé technologie.

Jaké jsou druhy technického dluhu?

Týmy rozhodující se pro rychlé a málo nákladné řešení namísto naplnění všech kvalitativních kritérií vědomě ignorují aspekty softwaru, o kterých ví, že jsou špatné, ale nemají čas je v daný moment opravit. V jiných případech může mít technický dluh podobu zastaralé nebo úplně chybějící dokumentace, příliš složitého kódu nebo neprovedení plánovaného testování.

Seaman & Guo (2011) rozdělují tyto typy technického dluhu do 5 základních kategorií:

• dluh za kód;
• dluh za testování – např, plánované testy, které nebyly provedeny;
• dluh v dokumentaci – např. chybějící nebo nedostatečná dokumentace;
• dluh za vady – např. známé vady, které nebyly opraveny;
• dluh za infrastrukturu – např. opožděná rozhodnutí o aktualizaci. 

Obecně však lze říci, že technické dluhy můžeme dělit dle jejich vědomého či nevědomého vytvoření. Vědomé technické dluhy vznikají v případě, kdy týmy úmyslně přijímají tento dluh jako strategický kompromis, aby mohly dodat produkt rychleji. S touto situací se lze typicky setkat u e-shopů v předvánoční sezóně či při tvorbě MVP – Minimum Viable Product, kde se používají pouze dočasná řešení při vývoji dalších funkcionalit.

V neposlední řadě se můžete setkat s dělením technického dluhu na krátkodobý a dlouhodobý. Krátkodobý dluh vzniká s předpokladem, že bude vyřešen v blízké budoucnosti, typicky v následujícím vývojovém cyklu. Týmy, které se rozhodnou pro krátkodobý technický dluh, musí mít pevný plán na jeho splacení, aby se zabránilo jeho přeměně na dlouhodobý problém. Naopak dlouhodobý technický dluh vzniká při užívání zastaralých technologií, se kterými jsou spojeny vyšší náklady na údržbu, nebo při tvorbě aplikace, jež je postavena na špatně navržené databázové architektuře nevyhovující velkému množství dat. Ačkoliv si vývojáři uvědomují nutnost redesignu, kvůli omezeným zdrojům a jiným prioritám tento úkol neustále odkládají. 

Jaké jsou následky technického dluhu?

Nejčastějším následkem technického dluhu jsou obtíže při plnění stanovených kvalitativních kritérií projektu. Nicméně tento dluh může vést také ke snížení výkonu, komplikacím při přidávání nových funkcí a zvýšením nákladů na další údržbu softwaru. V neposlední řadě je nutné zmínit také riziko, že se dluh vymkne kontrole a bude mít pro software devastující účinky (Seaman & Guo, 2011). 

Obecně jako nejčastější následky technického dluhu Rios et al. (2020) zmiňují:

• Zvýšení nákladů na údržbu a vývoj: Technický dluh často vede k vyšším nákladům na údržbu a rozšiřování systému, protože neefektivní nebo dočasná řešení vyžadují dodatečné úpravy a opravy​.
• Nízká udržovatelnost systému: Špatně navržený nebo zdokumentovaný kód komplikuje práci vývojářům, což může vést k nízké kvalitě výstupů a vyššímu riziku chyb.
• Zpoždění v dodávkách: Přítomnost technického dluhu může zpomalit další vývoj, protože je potřeba řešit stávající problémy, což zdržuje vydání nových funkcí.
• Finanční ztráty: Technický dluh může způsobit přímé ekonomické ztráty, například zvýšenými náklady na vývoj, nebo nepřímé ztráty v podobě snížené produktivity a výkonnosti týmu​.
• Rework a přepisování kódu: Mnoho částí systému může být nutné přepracovat nebo přepsat, což zvyšuje časovou i finanční náročnost projektu.

Jak snížit technický dluh?

Snížení či úplné splacení technického dluhu je klíčové pro prodloužení životnosti projektu, snížení nákladů na údržbu a vyhnutí se zbytečným „zdokonalovacím“ pracím (Seaman & Guo, 2011). Pro tyto účely existuje hned několik účinných metod:

• refaktorování kódu, což je proces, při kterém dochází k úpravě a zlepšení existujícího kódu bez změny jeho základní funkčnosti. Cílem je zvýšit čitelnost a efektivitu kódu, což snižuje pravděpodobnost chyb a usnadňuje budoucí údržbu;
• průběžná dokumentace, jež usnadňuje orientaci v projektu, což zvyšuje srozumitelnost kódu a usnadňuje jeho údržbu;
• kontinuální integrace a automatizované testování, které jsou důležité pro udržení kvality kódu a minimalizaci chyb v nových verzích;
• aktualizace technologií, které jsou užívány při vývoji webových stránek, včetně frameworků jako je Laravel nebo CMS jako je WordPress.

Seznam použitých zdrojů:

Alves, N. S. R., Mendes, T. S., Mendonça, M. G. de, Spínola, R. O., Shull, F., & Seaman, C. (2016). Identification and management of technical debt: A systematic mapping study. Information and Software Technology, 70, 100 – 121. https://doi.org/10.1016/j.infsof.2015.10.008

Cunnigham, W. (1992), The WyCash Portfolio Management System, in Addendum to the proceedings on Object-oriented programming systems, languages, and applications, pp. 29-30.

Rios, N., Spínola, R. O., Mendonça, M., & Seaman, C. (2020). The practitioners’ point of view on the concept of technical debt and its causes and consequences: A design for a global family of industrial surveys and its first results from Brazil. Empirical Software Engineering, 25(5), 3216 – 3287. https://doi.org/10.1007/s10664-020-09832-9

Seaman, C., & Guo, Y. (2011). Chapter 2—Measuring and Monitoring Technical Debt (M. V. Zelkowitz, Ed.; Roč. 82, s. 25 – 46). Elsevier. https://doi.org/10.1016/B978-0-12-385512-1.00002-5