Technologický dluh aneb Když si po sobě vývojáři neuklízí

Představte si, že pozvete své přátele na večeři. Když po výborném jídle všichni odejdou, zůstane vám doma spousta špinavého nádobí. Pokud jej neumyjete hned, druhý den s ním budete mít mnohem více práce. A když špinavé nádobí necháte žít svým životem ještě déle, budete asi brzy potřebovat novou kuchyň. Tento problém se vyskytuje nejen v kuchyni, ale i při vývoji softwaru a nazývá se technologický dluh. Pokaždé když přidáte nějakou novou funkcionalitu, zbude po vás nepořádek, který je potřeba uklidit (refactoring). Pokud jej nekontrolujeme a neopravujeme průběžně, zvětšuje se a může vést až k nutnosti přepisu celé aplikace, což je vždy ta nejdražší varianta.

Technologický dluh je nejtypičtější pro startupy, které místo kladení důrazu na kvalitu psaného kódu dávají přednost rychlosti vývoje. Tento jev je naprosto pochopitelný, protože startupy potřebují dostat produkt na trh v co nejkratší možné době. Je tedy zásadní, aby o technologickém dluhu, který vytvářejí, vývojáři věděli a brali v potaz, že jej musí co nejrychleji dostat pod kontrolu. K tomu se ale většinou dostávají až v momentě, kdy už může být pozdě.

Stále častěji se ovšem setkáváme s tím, že spousta společností o technologickém dluhu vůbec neví nebo má jen malé povědomí o tom, co tento pojem znamená nebo k čemu může vést. Největší hrozbou je narušení bezpečnosti, a to jak pro zákazníky, tak pro společnost, která software vyvíjí. Další riziko představuje nefunkčnost částí nebo celé aplikace. Dlouhodobou hrozbou je pak rostoucí složitost ve vývoji nových funkcí. Tu si lze představit jako stavbu domu – pokud odbydeme základy a budeme stavět dál a dál, dům se nám začne časem hroutit. Stejné je to i s vývojem softwaru, jakmile budeme mít jádro aplikace s velkým technologickým dluhem a budeme na něm stavět nové funkce, časem se nám vše rozboří a nebudeme schopni kód udržet a dále jej škálovat.

Tento problém stojí společnosti po celém světě ročně spoustu peněz. Pokud bychom to měli vyjádřit číslem, společnost Gartner již v roce 2015 odhadovala, že celosvětový technologický dluh dosáhne jednoho bilionu dolarů.

CAST Research Labs (dále jen CRL) vyčíslila průměrnou cenu za opravu technologického dluhu jednoho řádku kódu na $3,61. CRL postupovala tak, že zanalyzovala 1 400 aplikací, které dohromady obsahovaly 550 milionů řádků kódu. Těchto 1 400 aplikací získala CRL od 160 společností. Pokud vezmeme v úvahu průměrně velkou aplikaci, která obsahuje 300 000 řádků, technologický dluh dosahuje výše $1 083 000. Tato suma vyjadřuje náklady potřebné k tomu, aby byla aplikace funkční a neohrožovala chod společnosti, nejsou zde tak započítány úplně všechny chyby, které je třeba opravit, jen ty kritické.

Proč se tedy zabývat technologickým dluhem již od začátku vývoje a ne až později, resp. proč se snažit technologickému dluhu předcházet a stabilně jej zmenšovat? Kromě nutnosti vynaložení značných finančních prostředků nese tento problém spoustu dalších rizik. Jak již bylo zmíněno v předchozích odstavcích, hrozí především nefunkčnost aplikace, která může mít za důsledek odliv stávajících zákazníků, logicky odmítajících platit za nefungující aplikaci. Další problém představuje vynakládání mnohonásobně většího úsilí na udržitelnost konkurenceschopnosti aplikace, protože pokud nebudeme zvládat přidávat nové funkce včas, ujede nám vlak a jak noví, tak stávající uživatelé budou přecházet ke konkurenci s lepší nabídkou. Kromě těchto problémů nese technologický dluh i rizika v bezpečnosti aplikace, znemožňuje totiž schopnost reagovat na změny v technologických standardech, aktualizovat knihovny a opravovat bezpečnostní chyby dostatečně rychle.

Tyto bezpečnostní chyby nemusí vznikat pouze v aplikaci samotné, ale objevují se také v infrastruktuře, kterou aplikace používá (jde například o konfiguraci správného využití serverů, fungování skriptů atd.) Pokud spolu jednotlivé části kódu nebudou správně komunikovat, může to vést až ke ztrátě cenných dat.

V neposlední řadě komplikuje technologický dluh i udržení a rozšiřování týmu vývojářů. Dovedete si představit, že vás někdo najme jako kuchaře a ještě před tím, než se dostanete k vaření, budete muset umýt hordu nádobí?

Se vším výše zmíněným mohou v dnešní době pomáhat chytré nástroje, které měří kvalitu kódu automaticky, a tím šetří čas programátorům, kteří se mohou věnovat při code review (tj. kontrola nově napsaného kódu) tomu, jak nová funkcionalita funguje a nemusí řešit, zda byly zachovány správné standardy. Kromě urychlení celého vývoje pomáhají tyto nástroje snižovat fluktuaci a zrychlují nábor nových vývojářů.

S náborem pak tyto nástroje pomáhají v momentě, kdy se nováček učí standardy používané ostatními členy týmu. Jakmile totiž napíše část kódu, nástroj mu automaticky dá zpětnou vazbu a poradí, jak nalezené problémy opravit. Díky tomu se snižuje fluktuace nových členů týmu a také se urychluje zaškolení – lidé přijímají kritiku od stroje mnohem lépe než od lidí.

Jedním z takových nástrojů, který se vším výše zmíněným pomáhá, je Codeac.io, za nímž stojí tým lidí z Česka.

Myšlenku na vyvinutí tohoto nástroje dostal Michal Šimon po jeho zkušenostech ze Silicon Valley, kde pracoval pro startup a právě téma technologického dluhu řešili před úspěšným exitem. Díky překážkám, kterým čelili a získaným zkušenostem, se Michal rozhodl vytvořit Codeac.io, aby pomáhal vývojářům předcházet podobným problémům.

“Jak rádi v Codeac.io učíme naše uživatele – vždy zanechte kód v lepší kondici, než když jste ho našli,” dodává Michal.

Newsletter