Technický dluh - 1. část - Co? Proč? Jak ovlivňuje vaše podnikání?

Nejběžnější typy technického dluhu. Příklady technického dluhu

Podívejme se, na jaké typy technického dluhu obvykle narazíte. Martin Fowler na to napsal skvělý článek, s nímž souhlasíme. Existují v podstatě 4 typy technického dluhu.

1. Rozumný & záměrný - Jde o promyšlenou sázku. Tým ví, že technický dluh se hromadí, ale rozhodne se projekt i nadále dodávat. Toto řešení je přijatelné, pokud je riziko malé nebo je možný výnos z dřívějšího spuštění dostatečně vysoký na pokrytí "splácení" nákladů původního technologického dluhu.

2. Nezodpovědný & záměrný - To je ten nejhorší případ. Vývojový tým se záměrně rozhodne pro nejkratší cestu k dosažení konečného cíle, aniž by bral v úvahu důsledky technického dluhu, vznikající problémy a vyšší náklady v budoucnu.

3. Rozumný & nezáměrný - Tým je znalý, schopný, používá osvědčené postupy a volí nejlepší řešení, které v danou chvíli zná. Problém je v tom, že IT jako odvětví se neustále vyvíjí a každý rok existují nové způsoby, jak přistupovat k řešení různých problémů. To je také důvod, proč zdůrazňujeme, že technický dluh je součástí každého IT projektu. Během let existují lepší způsoby, jak řešit stejné problémy, takže k vylepšení vašeho projektu provádíte refaktoring. Agilní Manifest ve skutečnosti má skvělou úvodní větu:
   
   Objevujeme lepší způsoby vývoje softwaru tím, že jej skutečně vyvíjíme a pomáháme s ním ostatním.

4. Nezodpovědný & nezáměrný - Tým ignoruje designové postupy nebo pravidla čistého kódu, obvykle kvůli nedostatku zkušeností, aniž by si uvědomil, do kolika problémů se dostává.

Nejběžnější příčiny technického dluhu

Nyní známe nejběžnější typy technického dluhu, ale jaké jsou nejběžnější příčiny mimo ty výše uvedené?

• Časový tlak,
• nedostatečné testování,
• zastaralé technologie,
• absence jakékoli dokumentace,
• nepořádný kód,
• špatná architektura,
• nedostatek dovedností vývojového týmu.

Čas - Náklady - Kvalita

V business světě existuje několik "zlatých pravidel" a zde je jedno z nich. Ze známé trojice Čas - Náklady - Kvalita můžete mít pouze dvě. Pokud tlačíte váš vývojový tým k vytvoření něčeho levného a rychlého, nedostanete kvalitu. Pokud chcete kvalitu a rychlé dodání, nebude to levné. To platí ve vývoji zakázkového softwaru stejně jako kdekoli jinde, pokud ne více. Špatná volba dvou z těchto tří možností často způsobuje technický dluh.

Nejsme blázni a chápeme, že někdy je technický dluh nevyhnutelný a v konkrétním případě to dokonce dává smysl (např.: rychlý vývoj MVP pro ověření na trhu). V tomto případě, kdy máte omezené zdroje a chcete co nejdříve otestovat celý projekt, nemusí dávat smysl vybudovat složitou architekturu připravenou škálovat na miliony uživatelů, připravovat skvělé automatizované testy, různé sandboxy, celý proces CI/CD a další důležité aspekty moderního vývoje. Zaměřujete se prostě na co nejrychlejší dokončení. A to je v pořádku, pokud chápete rizika a budoucí náklady (v některých případech by mohlo být nutné dokonce přepsat celou první verzi aplikace).

Věc se má nicméně tak, že kalkulovaný technický dluh je bohužel obvykle součástí pouze malého procenta projektů.

Co obvykle v Moravio zaznamenáváme, když například zachraňujeme projekty, je přesný opak nebo přesněji řečeno, nezodpovědný & záměrný technický dluh z výše uvedeného popisu. Technický dluh je opomíjen, neustále roste, není zdokumentován a není spravován.

Je zde také ještě jedna věc, která by měla být řečena. IT odvětví se vyvíjí jako žádné jiné na světě. Technologie, které jsou špičkové letos, mohou mít příští rok výrazně lepší verze nebo alternativní technologie. Tak to prostě chodí. Měli byste se vždy snažit udržet svůj projekt aktualizovaný. Neříkáme, že potřebujete aktualizovat první den, kdy je vydána nová verze technologie (naopak to důrazně nedoporučujeme kvůli chybám, které obvykle v prvních dnech vznikají), ale je vhodné udržovat váš projekt na nejnovější stabilní a dlouhodobě podporované verzi v rozumném intervalu. V jistém smyslu lze toto samo o sobě také nazývat technologickým dluhem, což je důvod, proč na začátku článku hovoříme o tom, že technologický dluh je součástí každého projektu.

Jak technický dluh ovlivňuje váše podnikání?

Prostě řečeno, hodně. Zde je jen několik příkladů:

• rychlost vývoje a náklady na nové funkce,
• náklady na údržbu,
• spokojenost vývojového týmu,
• spokojenost zákazníků,
• vaše obchodní procesy,
• komunikace,
• a nakonec vaše pověst.

Vše závisí na charakteru vašeho podnikání. Vše to lze také přímo nebo nepřímo převést na finanční ztráty.

Hlavní věc, kterou si z tohoto článku odneste

Myslete na technický dluh jako na živou část vašeho projektu. Vyčleňte čas pro vaše vývojáře, aby se s ním mohli vypořádat. Monitorujte jej a dokumentujte (jednoduchý aktualizovaný úkol v JIRA nebo stránka v Confluence může udělat zázraky). Pracujte s vaším technickým dluhem a průběžně ho zmenšujte. To je jediný způsob, jak jej dlouhodobě udržet pod kontrolou. Pokud to neuděláte, mnohonásobně vyšší náklady vás pravděpodobně dříve či později doženou.

Příklad technického dluhu z praxe

V Moravio se kromě poskytování dedikovaných vývojových týmů také věnujeme co-developmentu & outstaffingu a záchraně projektů.

Právě na jednom z projektů, který jsme zachraňovali, chceme ukázat dnešní příklad. Projekt byl velmi zanedbáván a zahraniční klient se na nás obrátil velmi pozdě. Klient v té době také nebyl příliš zkušený. Takže si sám nevšiml problémů, dokud nebylo zřetelně vidět, že je něco špatně. Projekt byl o 2-3 hlavní verze PHP a Laravel frameworku pozadu, nepořádek v kódu, špatná architektura, tisíce zbytečných databázových volání, desítky nepoužívaných nebo neaktualizovaných NPM balíčků, šest různých knihoven pro práci s obrázky, jeden velký soubor pro CSS a JavaScript, špatné směrování URL, žádná dokumentace a testy. Na co si vzpomenete.

Jaké byly dopady takového stavu?

• Načtení většiny důležitých stránek trvalo více než 5 sekund. V extrémních případech některé stránky trvaly více než minutu načíst!
• Velmi pomalý vývoj, protože kód byl jeden velký nepořádek a vůbec nebyl organizován. Jeden příklad může být, že Laravel Blades byly používány zcela nesprávným způsobem. Laravel Blades mimojiné obsahovaly logiku JavaScriptu a PHP, tzn. to, co mělo být v Controller/Service/Repository, bylo přímo mezi HTML daného Laravel Blade.
• Projekt byl náchylný k bezpečnostním hrozbám. Důvodem bylo, že měl velmi zastaralé verze všech používaných technologií, které již nebyly podporovány. Navíc byl v takovém stavu, kdy již nebylo možné aktualizovat jádro systému Linuxového serveru bez aktualizace technologie projektu, což způsobilo další zranitelnosti vůči bezpečnostním hrozbám.

Nebojte se. Všechny problémy jsme nakonec úspěšně vyřešili, ale na příkladu výše je krásně vidět, do jakých technických i business problémů se můžete potenciálně dostat.

Tato část byla trochu teoretičtější. V další části vysvětlíme, na co si dát pozor, abyste odhalili technický dluh, jak se vypořádat s technickým dluhem a pár dalších příkladů z našich osobních zkušeností z první ruky.