Technický dluh - Část 2 - Na co si dávat pozor? Jak s tím v rámci agilního (scrum) vývoje pracovat?

Na co si dávat pozor pro odhalení technického dluhu v agilním či waterfall vývoji?

Hned na začátek je potřeba si říct, že odhalit to, že Váš problém je zrovna technický dluh nemusí být vždy jednoduché. Komplexní projekty, které dnes vznikají, mohou mít různé problémy od nedostatečného hardwaru, přes špatnou architekturu, složité a neefektivní algoritmy a další problémy.

Za druhé, pokud jste člověk, který nerozumí IT technologiím, většina technických informací kolem technického dluhu Vám velmi pravděpodobně nebude dávat moc smysl.

Pokud se vrátíme k našemu prvnímu dílu o technickému dluhu, pak už víte, co lze vlastně za technický dluh považovat, a že technický dluh je víceméně součástí každého dnešního IT projektu. Někdy je technický dluh dopředu kalkulovaná sázka s o to větším potenciálním ziskem. Někdy je to naopak jen nevědomost lidské mysli a nebo bezohlednost vývojového týmu. No v a posledním případem je to “jen” neskutečně rychlý růst celého IT odvětví a tak je možné, že to co je moderní a funkční dnes, může být za dva roky překonáno jinou a lepší technologií a pak už je na posouzení každého, zda by se taková technologie Vášemu projektu hodila nebo ne.

Z toho všeho vyplývá, že je potřeba soustředit se na pár základních bodů a při jejich dodržování budete ve většině případů mít vše pod kontrolou. V podstatě vše se pak točí okolo komunikace a transparentnosti vývoje. Komunikuje s Vámi vývojový tým o stavu Vašeho projektu? Probírá s Vámi otevřeně možnosti vývoje dalších funkcí, přičemž pokud by při zvolené možnosti řešení mohlo dojít k navýšení technickéhé dluhu, informuje Vás o tom? Probíhá tu a tam (většinou párkrát do roka větší či menší upgrade) aktualizace použítých technologií v rámci některého sprintu? Máte přístup ke zdrojovému kódu?

Pokud je vývojový tým transparentní, nemlží o stavu projektu a vše srozumitelně vysvětluje a v případě možnosti navýšení technického dluhu Vás také dopředu upozorňuje a žádá Váš souhlas, pak je vše pravděpodobně v nejlepší pořádku. Pokud jste například více technicky založeni, můžete mít na jednom místě také přehled o použitých technologiích a jejich verzích. Pokud se ale nic takového neděje, pak je vhodné jednou za čas pokládat vývojovému týmu několik otázek a dopídit se k jejich odpovědi.

Takové otázky jsou například:

1. Jak jsme na tom s technickým dluhem? Je něco, co nás dlouhodobě může negativně ovlivnit?
2. V jakých verzích jsou naše knihovny a technologie a jak moc pozadu jsme oproti aktuálním hlavním verzím? Je v nových verzích něco, co nám může pomoci?
3. Co jsou nyní naše nejpalčivější problémy v rámci technického dluhu a jak nás to ovlivňuje?
4. Je něco, co vývojovým tým brzdí v efektivním rozvoji nových funkcí? Co s tím můžeme dělat?

Toto je pouze základní sada různých dotazů, nicméně často Vás dovede k navazujícím otázkám a odpovědím.

V rámci této kapitoly ještě malá poznámka k používání nejnovějších verzí knihoven a technologií. Obecná zkušenost v IT je taková, že pokud to Váš projekt absolutně nepotřebuje, nebo klady nové verze technologie nepřevyšují nad zápory (například velké zvýšení rychlosti a počtu zpracování požadavků), vyplatí se vždy alespoň několik měsíců od vydání nové hlavní verze technologie počkat. Po vydání nové verze se často objevují ještě malé či větší chyby, které jsou s vydáním spojené nebo které objeví tzv. Early adopters, což jsou jednotlivci nebo společnosti, které na novou verzi updatují, protože musejí. Tyto chyby jsou pak běžně velmi rychle evidovány, opraveny a po pár týdnech či měsících je k dispozici v podstatě velmi stabilní verze, se kterou můžete bez problémů pracovat.

Jak s technickým dluhem pracovat v rámci agilního (scrum) vývoje?

Tuto pasáž už jsme lehce nastínili v našem prvním díle o technickém dluhu, nicméně opět si to zde lehce zopakujeme.

1. Berte v potaz, že technický dluh se týká každého projektu. Někde se jedná jen o promyšlený dluh s vidinou zisku (v jakékoliv formě), někdy je situace horší / jiná. V realitě to znamená vyhradit si čas a tedy i finanční prostředky na jeho řešení.

2. Evidujte, o co přesně jde, snažte se část po části technický dluh odmazávat. Na evidenci bohatě stačí jedna stránka v Confluence, otevřený tiket v GitHubu, nebo task v JIRA, který má Váš product manager pod palcem.

3. Pokud potřebujete provést rychlý vývoj i za cenu toho, že navýšíte technický dluh, abyste dosáhli nějakého milníku, počítejte s tím, že si v budoucnu musíte najít čas, abyste se tomuto nově vytvořenému technickému dluhu opět věnovali.

4. Pokud Vám to dává smysl, přizvěte do Vašeho projektu experta třetí strany, který může provést technický audit.

5. Nenechávejte technický dluh hnít. Čím déle se mu nikdo nebude věnovat, tím horší mohou být pro projekt dlouhodobé následky. Prioritizujte.

6. Mějte zavedené procesy, které mohou technický dluh výrazně zmírnit. To mohou být například automatizované testy, pravidla pro vývoj nových modulů či komponent, striktnější code-reviews atp.

7. Důležitá je ale také komunikace vývojového týmu a Vás jako klienta. Bavte se tedy o této problematice otevřeně a jste na nejlepší cestě vždy zůstat o jeden krok napřed.

Pár příkladů technického dluhu, které jsme za léta naší praxe již viděli

Již v první části našeho krátkého seriálu o technickém dluhu jsme Vám ukázali jeden příklad takového problému a jeho dopady na projekt. Dnes zde máme další tři různé příklady, které jsme od roku 2011, kdy je Moravio na trhu, zažili.

Špatný návrh databáze

Tato situace se stala v rámci jednoho projektu, který jsme v Moravio převzali pod svá křídla. Při převzetí projektu jsme zjistili, že projekt je databázově špatně navržený. Jeden hlavní objekt, který se při určité akci na portálu vytvořil a zároveň pod sebou sdružoval několik entit, vždy vytvářel svou vlastní kopii struktury databáze, do které ukládal data. Díky tomu se celá databáze stala velmi rychle nepřehledná a navíc díky špatnému pojmenování tabulek a přidružených entit bylo velmi složité cokoliv dohledávat. Tato architektura také měla přímý vliv na vývoj a výkon některých funkcí, které nebylo možné standardně upravit či implementovat. S rapidním růstem projektu bylo nutné provést úpravu databáze a vše sjednotit. Díky tomu došlo ke zrychlení práce vývojového týmu, refaktorování části kódu komunikující s databází a také zvýšení přehlednosti celého databázového schéma.

Zanedbávání aktualizace technologií

Toto je jeden z velmi častých důvodů, proč mají projekty technický dluh a tento příklad je uveden na jednom projektu, kde jsme v rámci Co-developmentu dodávali naše služby. Projekt využívá jako hlavní technologii jazyk PHP. To je dnes velmi schopný jazyk, který umí defakto vše, co jakékoliv jiné, moderní a pokročilé programovací jazyky (JavaScipt, .NET Core etc.). Major verze PHP nicméně často obsahují velký seznam změn a také hodně práce přímo na jádře tohoto jazyka. Klient v rámci tohoto projektu udělal z našeho pohledu dvě hlavní chyby. První je, že velmi dlouho otálel s updatem na novější technologii, protože v jeho případě nešlo “jen” o jednoduchý update, ale bylo potřeba také refaktorovat část kódu, na což bylo potřeba naplánovat více času. A druhý je, že když už se do updatu klient pustil a nějakou dobu na něm pracoval, nakonec jej zase uložil k ledu, protože se objevily jiné a větší priority. Celý projekt se v mezičase výrazně rozrostl kvůli novým funkcím pro zákazníky a také stihla vyjít další nová hlavní verze PHP. To ve výsledku vedlo k tomu, že se na updatu pracovalo jen skokově a velmi pomalu a vývojáři ztratili přehled. Tím pádem byla práce velmi neefektivní. Výhody updatu na novou technologii však byly pro klienta značné - obrovské zrychlení aplikace, zpracování většího množství požadavků zákazníků ve stejný čas a také navýšení bezpečnosti aplikace.

Nevytváření automatizovaných testů, potažmo netestování vůbec

Dnes najdete stále mnoho projektů, ve kterých nedochází k vytváření automatizovaných testů vývojovým týmem. Ano, můžete namítat, že takové automatizované testy stojí čas a peníze a vlastně to není moc nikde poznat, ale to by byl mírně naivní pohled na věc. Automatizované testy existují mimojiné proto, aby nahradily lidský mozek a vašemu projektu (a vývojářům) dali potřebnou jistotu a stabilitu. Od jisté velikosti vašeho projektu již totiž není možné v našich mozcích udržet veškeré propojení a s tím související veškeré scénáře chování vašeho projektu. Na tyto případy pak vznikají právě automatizované testy, které při každém nasazení nové funkcionality vždy testují stejnou konkrétní funkcionalitu. Uvedu velmi jednoduchý fiktivní příklad:

Ve Vašem projektu používáte přihlášení pomocí třetích stran. Jedná se o Google, Microsoft, Facebook a Twitter. Z důvodu aktualizace API na straně Facebooku potřebujete upravit přihlášení přes Facebook. Úpravu provedete, nasadíte na testovací prostředí, otestujete, nasadíte na produkci, vše funguje. Jenže při úpravě došlo také k upravení zdrojového kódu, které používají poskytovalele přihlášení Google, Microsoft a Twitter. Pokud ve Vašem projektu neexistují automatizované testy, pak se tento problém s největší pravděpodobností dozvíte až v momentě, kdy Vám na Vaší zákaznické lince začnou létat tikety a zvonit telefony od naštvaných uživatelů, kteří nemohou Vaši aplikaci používat a řešíte hotfix. V případě, že by ale existovaly správně napsané automatizované testy, již při nasazení na testovací prostředí by došlo k odhalení, že funkce přihlášení skrz Google, Microsoft a Twitter neprošla testem a tak se vývojář podívá nejen na funkci, kterou skutečně upravoval (Facebook), ale zároveň upraví i funkci, se kterou pracují další poskytovatelé přihlášení (Google, Microsoft, Twitter).

Takže ano, automatizované testy sice stojí čas a peníze navíc a nevyřeší všechny chyby v projektu (chyby jsou stejně jako technický dluh součástí každého projektu). Ale v dlouhodobém horizontu Vám ušetří násobky takto stráveného času a peněz a to hlavně díky tomu, že se celý vývojový tým může věnovat vývoji nových funkcí a netrávit čas neustálou opravou chyb. Osobně jsem viděl i případy, kdy vývojový tým trávil v podstatě polovinu veškeré své kapacity jen opravou chyb a to je něco, co na svém projektu nechcete.

Tímto je náš dvoudílný seriál o technickém dluhu završen a nezbývá než Vám popřát, abyste se s příklady výše zmíněných problémů setkávali co nejméně.

Pokud potřebujete provést audit Vašeho současného řešení, nebo celkově převzít aktuální projekt, ozvěte se nám a společně vymyslíme další kroky.