Technický dluh

Hacknem to tam?

S technickým dluhem bojují všichni, je to takový přízrak, jenž obrovským způsobem ovlivňuje mnoho věcí v softwarové firmě. Smyslem tohoto článku je poskytnout praktickou příručku popisující, jak ním pracovat a jak předcházet situacím, kdy je aktivně výtvářen.

 

TD-death

 

Co vlastně technický dluh je

V úvodu článku jsem napsal, že technický dluh je přízrak. Na první pohled se to může jevit jako příliš melodramatická metafora, ve skutečnosti ale mají oba termíny mnoho společného. Přízrak je z definice něco nejasného, obávaného a každý si ho vysvětluje po svém.

První problém technického dluhu je, že každý vývojář pod tím termínem chápe něco jiného. Zvláště obtížné je dohodnout se ve skupině na tom, co konkrétně ještě technický dluh je a co už není.

Záměrně jsem oslovil několik vývojářů a business lidí a požádal je o jejich vlastní definici technického dluhu. První překvapivý poznatek byl, že kromě konkrétních odpovědí jsem dostal i mnoho prohlášení bez obsahu. Takové ty prázdné věty, že „technický dluh je něco, s čím se něco musí udělat“. Podobný pocit jsem si přinášel i z některých setkání v softwarových firmách. Všichni se zlobí, že se technický dluh neřeší… ale když se zeptáte, co si pod termínem technický dluh představují, nastane ticho.

V dobrých odpovědích převládal názor, který by šel zobecnit na výrok:

Technický dluh je veškerý kód, který není napsán tak, že nejlepším možným způsobem řeší konkrétní zadání.

Velmi zajímavé vstupy přišly ohledně toho, že kód muže být psán jiným než ideálním způsobem buď vědomě nebo také nevědomě. Na jejich základě by se výše uvedená definice mohla upravit na:

Technický dluh je veškerý kód, který není vědomě napsán tak, že nejlepším možným způsobem řeší konkrétní zadání.

Já osobně ale preferuji tu první definici. Viděl jsem mnoho programátorů jejichž znalosti byly tak špatné, že v principu vytvářeli pouze technický dluh a nebyli si toho vůbec vědomi. Pokud vám definice přijde jako příliš vzletná a nepraktická, tak vězte, že je to záměr. Jedna věc je totiž definice technického dluhu a druhá věc je to, co s ním můžeme dělat. Je velice pravděpodobné, že nikdy nebudete schopni psát ideální kód. Záleží na vás kam si laťku sami položíte.

Pro technický dluh je příznačné i to, že co není technický dluh dnes, se může technickým dluhem stát v budoucnosti. Například příchodem nových technologií, postupů, poznatků.

 

matrix-td

 

Co tedy technický dluh je? Pojďme si to popsat pomocí metafory. Možná vám to přijde jako zdlouhavá odbočka, ale pokud si nejste jisti, jak o technickém dluhu mluvit netechnickými lidmi, metafora může být jednoduchým způsobem, jak jim tuto problematiku přiblížit. Společné pochopení technického dluhu a jeho důsledků zlepší otevřenost a upřímnost komunikace ohledně tohoto ožehavého tématu.

 

Technický dluh vs bankovní úvěr

Technický dluh byl pojmenován dluhem z dobrého důvodu. Dluh je něco, co když necháme být, tak bude skrze úroky růst a bude nám způsobovat čím dál tím větší problémy. U bankovního úvěru to je všem jasné a myslím, že nesplácet půjčky je vlastností skutečně otrlých nebo zoufalých lidí.

Na druhou stranu si v dnešní době bereme půjčky téměř na všechno. Když na začátku projektu, startup je ideálním příkladem, dáváme přednost rychlému vytváření různých featur tak, abychom zaujali potencionální zákazníky, ověřili si svůj business plán nebo ukázali zákazníkům, jak pružně dokážeme reagovat na jejich požadavky, je to úplně stejná půjčka, kterou bude potřeba někdy splatit. Půjčili jsme si kapacitu týmu a využili ji jednostranně pouze k doručení business featur bez ohledu na technickou kvalitu práce. Když si vezmete bankovní úvěr, tak v drtivé většině případů začnete od dalšího měsíce splátky splácet včetně úroků. To se ale u technického dluhu moc často neděje. Začne se o něm mluvit až v okamžiku, kdy to je skutečný problém, který začne ovlivňovat doručování featur. Když nám na dveře klepe exekutor…

Divoká počáteční fáze projektů, kdy se technický dluh aktivně a vědomě vytváří, vždy nějakou dobu trvá, spousta lidí si zvykne, že je to standard práce a fungování celé firmy. Vy sami jste chtěli svým zákazníkům ukázat, jak pružní dokážete být. Tím, že jste ignorovali technickou stránku odvedené práce, jste jim ale ukazovali dlouhodobě neudržitelnou realitu. To samé platí o vašich business lidech, i oni se naučili, že všechno se dá udělat hned. A ruku na srdce, možná že i vy, technici, jste to v té první fázi cítili jako ten správný přístup a najednou jim říkáte na všechno ne. Mimochodem tohle je i okamžik, kdy spousta společností dojde k rozhodnutí, že potřebují začít dělat scrum. To aby ochránili vývojáře před nájezdy otravných obchodníků. A tak se reputace scrumu a agilního vývoje v očích business lidí neprávem ještě více zhorší…

Tohle je velký problém a mohl bych jmenovat hodně společností, kde jsem tenhle příběh slyšel a stejně tak jsem tam slyšel povzdechnutí „a co teď s tím?“

 

Důsledky ignorování technického dluhu

Vytváření a ignorování technického dluhu v průběhu času zvyšuje náklady na přidávání nových featur. Ruku v ruce s tím klesá schopnost reagovat na požadavky zákazníků. Článek Softwarová sebevražda popisuje stav, kam se může softwarová společnost dostat, když technický dluh dlouhodobě neřeší a zaměstnanci ani nevědí, že něco takového existuje.

Následující graf ilustruje, co technický dluh způsobuje. Je to progresivní zvyšování extra nákladů na provádění jakýchkoliv změn v softwarovém produktu včetně doručování nových featur.

graf-td

 

Pokud se pokusíte obrázek sdílet s vašimi business lidmi, chtěl bych vás varovat před jednou nepříjemnou zkušeností: business lidé obecně význam problémů s technickým dluhem podceňují a dál tlačí na doručování featur na úkor zvyšujícího dluhu. Vysvětlování a osvěta proto musí být trochu sofistikovanější a dlouhodobější než pětiminutový rozhovor a ukázání obrázku.

Kdybo šlo pouze o extra náklady, tak by to asi spousta společností zkousla. Ono je toho ale víc. Z vlastní zkušenosti mohu říci, že technický dluh má dále zásadní vliv na následující:

  • vytváření špatných odhadů, kdy bude práce dodělána. Odhady se záměrně needukovaně nadhodnocují (padding)
  • doručení všeho trvá déle než by mělo a než se původně naplánovalo. V kódu čekají na vývojáře překvapení, která při plánovaní práce nikdo neočekával a jejichž řešení konzumuje výraznou část času.
  • s rostoucím tlakem na doručování změn a ignorováním technického dluhu roste pasivita a frustrace vývojářů. Sami vedomě implementují vše pouze pomocí quick hacků a přestávají doufat v jakékoliv změny v přístupu k práci.
  • quick hacky jsou ve finále znát na konzistenci či spíše nekonzistence celého produktu, jeho chybovosti a stability a to i z pohledu uživatelů.
  • dovolil bych si i tvrdit, že strategie práce s technickým dluhem má velký vliv na fluktuaci dobrých zaměstnanců. Pokud dobrý vývojář cítí, že nemá prostor svou práci dělat dobře, roste jeho nespokojenost a pravděpodobnost, že vás opustí je velká. Bohužel, lidé kterým technický dluh nevadí, zůstávají a produkují ho vesele dál.
  • v neposlední řadě, technický dluh je jedním z faktorů, který vytváří propast mezi business a software lidmi. O tom trochu více v následujících řádcích…

 

 

Jak z toho ven

Zde je soubor 12 pravidel, které jsem si během své praxe téměř 20-ti leté praxe vytvořil. Není to vše, co se dá dělat, určitě mi spousta věcí uniká a jiné jsem zapomněl zmínit. Pokud ale budete níže uvedená pravidla aplikovat, určitě vám to v boji s technickým dluhem pomůže… A pozor, důležitá poznámka, odpovědnost za technický dluh a jeho likvidování mají software lidé, takže to jsou pravidla pro vás…

 

#1 Přiznejte, že existuje

Otevřeným přiznáním existence technického dluhu zvyšujeme transparentnost celého prostředí. To nám dává prostor na mnohem upřímější komunikaci. Právě toto může radikálním způsobem zlepšit mnoho business rozhodnutí, která se dělají. Business lidé mají šanci pochopit technickou stránku problémů v produktu. Přiznání existence technického dluhu dává možnost na něm skutečně a legitimně pracovat. Z přízraku se stane běžná práce a bude se s ní tak i pracovat. Schovávání naopak vede maximálně ke guerilovým akcím, které ve finále produkují pouze další technický dluh, neupřímnost, a vytváří nedůvěru. Znáte ty situace: na čem ten člověk pořád pracuje???

 

#2 Nevytvářejte nový

Bez ohledu na to, jak moc je váš projekt technickým dluhem zatížen, přestaňte ho vědomě vytvářet během práce na nových featurách. Jestli vám něco může skutečně pomoci, tak je to code review. Code review vám poskytne dostatečně bohatý vstup na to, abyste si postupně vytvořili agreementy definující, co považujete za technický dluh a jak s ním pracovat. Agreementy dávejte radši dohromady na retrospektivě, za chodu při práci by to mohlo být příliš třeskavé téma.

Jakmile agreementy existují, sepište je a vyvěste je na viditelné místo v kanceláři nebo si udělejte checklisty a všichni se je přilepte na monitor.  Ukázka takového checklistu ze začátků Netsafe…

 

checklist

 

#3 Přemýšlejte nad ním na všech úrovních

Technický dluh vzniká na úrovni jednotlivých commitů, tasků, user stories, velkých projektů a architektury celého systému. User stories by neměly za sebou zanechávat stopu technického dluhu. Pokud jste si z nějakého důvodu pomohli zkratkou a technický dluh vznikl, netajte to, mluvte o tom otevřeně. Taková situace je perfektní téma na retrospektivu. Možná, že se pokoušíte doručovat víc, než je vaše kapacita a každá user story tak končí dohackováním posledních kousků práce bez ohledu jak to uděláte. Pokud takhle probíhá každý sprint, asi jen obtížně budete hledat čas na řešení technického dluhu.

 

#4 Najděte způsob, jak se věnovat existujícímu

Ať chcete nebo ne, ve vašem projektu vždycky nějaký technický dluh bude. Buď ho aktivně vytváříte nebo jste ho získali jako dárek od kolegů z minulosti. V každém případě si musíte najít způsob, jak se mu průběžně věnovat a odstraňovat ho. Existuje mnoho způsobů, já zde doporučím dva, které se mi v praxi ověřili jako hodně efektivní. Oba jsou založeny na záměrném vytvoření prostoru pro práci na technickém dluhu, říka se tomu slack.

Split na úrovni limitů na WIP

Pokud používáte scrum nebo kanban, nejspíš na vašich tabulích (nebo jirách, trellech a podobně) limitujete množství WIP (work in progress). Přiložený obrázek ukazuje board, na kterém se tým o 5 členech rozhodl věnovat 20% svojí kapacity práci na technickém dluhu:

board-td

Horní část tabule (swimline) je určená pro task karty User stories a bug karty. Swimline Technical Debt je určena výhradně pro karty s technickým dluhem. Pomocí nastaveného WIP limitu bude vždy jedno místo vyhrazeno pro práci na TD a nemůže být obsazeno prací na User story. Toto částečně snižuje výkon týmu, co se týče featur, ale garantuje průběžné zpracovávání technického dluhu. V ten samý okamžik ale platí, že v jeden okamžik nemůže tým pracovat na víc jak jedné TD kartě. Barevné odlišení karet výrazně zvyšuje čitelnost tabule.

Project days

Můžete to nazvat jakkoliv, v principu jde o to, že část pracovního týdne vyhradíte na cokoliv jiného, než je běžná práce. Například, ve společnosti Netsafe se kdysi z jednoho dne v týdnu, z pátku, udělal takzvaný Project Day. Vývojáři měli možnost v ten den pracovat na svých vlastních projektech, vzdělávat se a podobně. Bylo tam ale několik podmínek. Ačkoliv se projekt mohl týkat čehokoliv, i věcí, které neměli nic společného s prací, musel každý svůj projekt představit ostatním kolegům a každý pátek pak při společné snídani s celým týmem sdílet své poznatky o tom, jak mu nebo jí projekt jde. Druhá podmínka byla, že všichni musí do práce přijít. Třetí podmínkou byla skutečnost, že když budou jakékoliv problémy s produkčním prostředím nebo bude zásadní problém s dodržením nějakého deadline, v pátek se bude pracovat jako v jakémkoliv běžném dni.

Světe div se, na začátku téměř každý začal pracovat na svém soukromém projektu (např. http://www.albumino.com/), časem se, ale lidé začali víc a víc věnovat věcem, které se týkali jejich práce, ale neměli na ně během běžných pracovních dní čas. A tak si jednotlivci brali na starost řešení backlogu technického dluhu, zlepšování bezpečnosti a performance projektu, zlepšovaní deployment procesu a vlastního develového prostředí. Do dnešního dne považuji pátky v Netsafe za nejproduktivnější dny v týdnu.

 

#5 Manažujte si ho sami

Nikdo z firmy nerozumí technickém dluhu víc než vývojáři. Stejně tak vývojáři vědí, které neduhy v kódu je nejvíce brzdí. Kdo jiný by tedy měl o práci na technickém dluhu rozhodovat?

Má to ale jeden zádrhel. Už jsem zmínil, že business lidé mají tendenci význam technického dluhu podceňovat. Vývojáři ho naopak často nekriticky přeceňují. Proto je potřeba vytvořit bezpečný rámec, ve kterém se bude technický dluh řešit a v tomto rámci dát vývojářům plné pole působnosti a nechat to na nich. Bezpečným rámcem myslím rozumnou alokaci času a systém evidence toho, na jakém technickém dluhu se pracuje.

Implementací výše uvedeného může být mnoho. Na ukázku uvádím opět jeden osvědčený model. (viz ilustrační obrázek u pravidla #4).

Karty, které řeší technický dluh jsou snadno odlišitelné od ostatních. Na ilustračním obrázku jsou žluté. Na tabuli se pohybují ve své vlastní swimline. Pokud kdykoliv z vývojářů někde zaregistruje technický dluh jehož řešení nespadá do práce, kterou právě dělá, jednoduše ho popíše na žlutou TD kartu a dá jí do TODO sekce pro technický dluh na tabuli svého týmu. Je zodpovědností vývojářů, aby si vytvořili rituál, při kterém se navzájem informují o TD kartách, jejich významu a prioritě. V Netsafe jsme tento rituál nazývali Přebírání TDčka. Scrummaster nevstupuje do obsahu diskuze, pouze hlídá, že:

  • v TODO není příliš mnoho karet. Pokud tomu tak je, vyzve tým k přebrání a pročištění fronty. Téměř vždy se tam v takové situaci najdou karty, které stejně nikdo právě nechce a nebude řešit. Takové TD karty jsou zahozeny. Pokud se na stejný problém narazí znovu, tak pravděpodobně vznikne opět i nová TD karta. Vývojáři se takto i učí chápat prioritu jednotlivých problémů a mají možnost je prodiskutovat. Dost často skutečnost, že karta bude zahozena, vede k otevřené komunikaci o tom, co je vlastně na kartě skutečně napsáno.
  • dbá na to, aby se dodržoval WIP limit na TD. Jinými slovy, žlutá TD karta se nikdy nedostane do WIP slotů určených pro karty User Stories.
  • na kartách technického dluhu dlouhodobě nepracuje pouze jeden člen týmu. Práci na technickém dluhu by se měli věnovat všichni členové týmu rovnoměrně. Zlepšuje to jejich dovednosti a nedochází k tomu, že by někdo jednostranně ovlivňoval architekturu celého projektu.

Tu a tam vznikne situace, kdy někdo opravdu těžce snáší fakt, že mu byla jeho TD karta vyhozena. Pokud máte ve vašem pracovním prostředí dobře nastavený ekvivalent výše zmíněných Project days, má takový člověk dost prostoru svou kartu vyřešit. Pokud ne, tak je to dobré téma na retrospektivu.

 

#6 Řešte ho, když se s ním potkáte

Pokud pracujete na user story a setkáte se s komplikací, která vám brání práci dokončit technicky dobře zvládnutým způsobem – nejspíš jste se dostali do oblasti zamořené technickým dluhem. V takový okamžik je preferovaným způsobem vyřešení technického dluhu, který vám brání v doručení featury, na které pracujete. Pokud tak neučiníte, pouze do kódu zanášíte další technický dluh. Jako se vším, je tady jedno ale. Pokud by řešení technického dluhu zásadním způsobem ovlivnilo dokončení vaší práce, tedy z práce na jeden den by stal mini-projekt pro jednoho člověka na celý týden, určitě zvažte následující alternativy:

  • svolejte tým a proberte situaci s ostatními. Možná, že dohromady dáte efektivnější řešení daného problému.
  • vytvořte TD kartu, která bude daný technický dluh adresovat a dejte jí do TODO fronty na tabuli.
  • pokud je to opravdu velký problém, přineste ho jako vstup na retrospektivu nebo udělejte speciální meeting s týmem, scrummasterem a product ownerem a zamyslete se nad systémovým řešením.

Jedna praktická rada, pokud pracujete na featuře a zároveň přitom musíte řešit technický dluh, rozdělte práci na doručení featury a práci na technickém dluhu do separátních commitu do version control systému. Výrazným způsobem to usnadní code review a chápání významu jednotlivých commitu. Pokud to budete mixovat, je hodně pravděpodobné, že vaše commit hlášky budou spíše popisovat práci na featuře na úkor popisu práce na technickém dluhu.

 

#7 Řešte historickou zátěž u legacy projektů

Slovo legacy je téměř synonymem slovního spojení technický dluh. Staré systémy přicházejí se slušnou zátěží z mnoha důvodů:

  • způsob přístupu k vývoji software se obecně zlepšuje
  • technický dluh se u nových projektů často ignoruje, nálepka legacy je jim přiřazena právě v okamžiku, kdy je míra technického dluhu už neúnosná
  • jsou napsány v jazycích, které umožňovali snazší vytváření technického dluhu

Problém legacy projektů je, že dokážou být natolik zatíženy technickým dluhem, že veškerá práce, kterou děláte je pouze servisováním technického dluhu.  V takovém případě si nevystačíte pouze s řešením jednotlivých dílčích problémů. To by mohlo být dokonce kontraproduktivní. Technickým dluhem může být i celá architektura software. Udělejte si vizi jakou architekturu by celý projekt měl v budoucnosti mít, jaké největší problémy tam vidíte a toto pak řešte systémově.

Nejsem příznivcem čistě technických user stories, ale v takovýchto situacích může být hodně užitečné udělat například několik user stories, které se pokusí pročistit nejdůležitější části software. Dobré pravidlo je soustředit se na tu část software, která adresuje největší čast vaší business value. Možná že zjistíte, že 90% business value vytváří pouze 10% procent zdrojového kódu. Součástí této práce je samozřejmě implementace high-level testů, které vás budou chránit před chybami, kterým se při práci na legacy systému nevyhnete. Skvělý zdroj informací na toto téma je kniha od Michaela Featherse Working Effectively with Legacy Code.

Pokud pracujete v prostředí, kde je technického dluhu hodně, vytvořte si dostatečnou rezervu na práci s ním a berte jí jako nedílnou část vašeho tempa / kapacity práce. Je to dobrý způsob, jak se dostat k realističtějším odhadům (story points, čas doručení a podobně) a plánovaní práce. Například zvyšte WIP limit TD karet na úkor práce na feature User stories.

 

#8 Buďte opatrní s user stories řešících pouze technický dluh

Člověk může mít pocit, že vývojáři budou nejšťastnější, když budou moci pracovat primárně na odstraňování technického dluhu a zlepšování aplikace po jejích technické stránce. Možná ano, ale ne dlouhodobě.

Dlouhodobá odstraňovaní technického dluhu bez zavádění změn v aplikaci jako takové je úmorné. Z vlastní zkušenosti mohu říct, že to vývojáře přestane bavit a vlastní kvalita práce klesne. Byl jsem svědkem situací, kdy si vývojáři upřímně stěžovali na to, že už mají těch čistě technických user stories plné zuby.

U technického dluhu se totiž často špatně vyjadřuje, kdy je práce dokončena (definition of done). Obecné hlášky typu „zlepšit architekturu“, „přepsat podle SOLID“ a tak dále jsou jenom vstupenkou na dlouhý výlet zakončený neúspěchem.

Pokud je to možné, vždy se pokuste řešení technického dluhu spojit s doručováním featur. Nechť business logika určuje architekturu. A technický dluh řešte v kontextu reálných problémů a chtěných vlastností. Nevymýšlejte hypotetické situace a nevytvářejte dokonalá všeobjímající univerzální řešení – vetšinou je nepotřebujete.

Když už musíte udělat čistě technickou user story, snažte se, aby definition of done bylo co možná nejvíce konkrétní a ověřitelné. Ujistěte se, že business lidé plně chápou, proč to musíte udělat a jaký přínos výsledná práce bude mít. Vysvětlete jim to pomocí příkladů, často je pro ně těžké chápat smysl takových user stories.

 

#9 Společně se zlepšujte

Jak bylo řečeno v úvodu, každý z nás si pod heslem technický dluh představuje něco jiného. Každý z nás má také jiné hranice, kam až při řešení dluhu chce jít a každý z nás má jinou úroveň znalostí programování. Aby se vám s technickým dluhem lépe pracovalo, musíte se v týmu snažit docílit vysoké úrovně společného porozumění (viz článek Smysluplné porady a společné rozhodování) a na základě tohoto porozumění udělat dobré dohody o tom, na jaké typy technického dluhu se budete soustředit a jak ho budete odstraňovat.

Aby pochopení bylo co možná největší doporučuji sadu rituálů z praxe:

  • Coding Dojos. Společná práce týmu u jednoho počítače zaměřená na hledání možných řešení dané situace. Dojo je cvičení a neočekává se, že při něm vznikne cokoliv, co by se stalo součástí vaší aplikace. Vývojáři se střídají u počítače, sdílejí svoje názory, společně hledají a objevují různé přístupy ke stejnému problému. Například si společně vyzkouší refaktorovat jeden kousek kódu deseti různými způsoby (viz foto níže)
  • Společné čtení knih. Kdysi jsme zabředávali do nekonečných diskuzí co je a co není clean code. Problém byl vyřešen tím, že jsem koupil všem lidem v týmu knihu Clean Code. Každý týden si každý z nás přečetl jednu kapitolu a každý týden jsme měli hodinovou schůzku na sdílení toho, jak určité věci chápeme a jak by šly aplikovat v naší firmě. Byl to dobrý zdroj námětů na Coding Dojos.
  • Přednášky. Pokud někdo z nás měl potřebu posunout některé technické aspekty aplikace dopředu, mohl na to téma udělat přednášku a pro svojí ideu tak získat více příznivců. Kromě zlepšování společného pochopení aplikace, se takto lidé i navzájem vzdělávali a přednášející si zdokonaloval své prezentační dovednosti.
  • Devel news. Pravidelně jsme se scházeli a probírali ryze technické změny v aplikaci. Devel news nejsou dema nebo sprint reviews. Jsou to diskuze, při kterých si jednotlivci i týmy mezi sebou vyměňují informace o technických změnách, které v nedávné době implementovali.

Účast na všech těchto aktivitách by měla být vždy dobrovolná.

coding-dojo

 

#10 Mějte pochopení pro business lidi

Úkolem obchodníků je prodávat. Aby obchodníci zákazníka zaujali, musí pro něj mít něco, co potřebuje. Ve světě software se to často dělá pomocí poskytnutí featur, které ten který konkrétní zákazník vyžaduje nebo vytvoření celé customizované verze produktu. Slovo poskytnutí by se ale mělo asi nahradit slovem slíbení. (viz článek Product Owner Survival Handbook).

Tohle je jedna z velkých třecích ploch mezi obchodníky a vývojáři. Technicky orientovaní zaměstnanci mají potřebu obchodníkům vyčítat slibovaní nerealných termínů a featur. Jenže otázkou je, co jiného může obchodník dělat. Pokud čtete tento článek, tak existuje poměrně velká pravděpodobnost, že je váš projekt zamořen technickým dluhem, projekty se vlečou a když se vás obchodník zeptá, jak dlouho bude implementace nějaké nové featury trvat, tak mu poskytnete buď extrémně dlouhý (rádoby bezpečný) odhad nebo případně odhad, který je stejně nereálný jako ten, co si vymyslí obchodník sám.

Mějte na paměti, že ať už špatný odhad nebo nereálnou featuru vytvořil kdokoliv, nakonec je téměř vždy obchodník ten člověk, co sedí u zákazníka a musí mu vysvětlovat, proč to není ještě hotové. To není příjemná situace.

Tohle byl trochu delší úvod k jednoduchému prohlášení: Stejně tak jako business lidé musí chápat důležitost odstraňování a nevytváření technického dluhu, tak i software lidé musí chápat, že jejich produkt existuje právě proto, aby co nejlépe a co nejdříve řešil potřeby zákazníků.

Proto se dá říci, že u implementace téměř každé nové featury by se měl hledat rovnováhu mezi technickou dokonalostí implementace a orientací čistě na doručení featury. Pokud jste se rozhodli dát přednost rychlému doručení, je to stejné, jako když si vezmete finanční půjčku – měli byste jí v brzké době splatit nebo jí začít splácet formou splátek. A i přesto to může být smysluplné…

 

#11 Mějte vizi ohledně architektury vaší aplikace

Agilní vývoj software má mnoho výhod, má však ale i svá úskalí. Nedá se říct, že by tato úskalí byla nedílnou součástí agilního přístupu, většinou jsou spíš důsledkem určitého nepochopení nebo špatné implementace agilního vývoje v konkrétním prostředí.

Jedním z takových problémů je skutečnost, že přílišný důraz na doručování práce v malých celcích (user stories) může vést k velké fragmentaci architektury, datového modelu, user interface a tak dále.  Při práci na malých stories, zvláště pokud se na vytváření produktu účastní víc týmů,  je snadné sklouznout k modelu, kdy se každá jednotlivá věc implementuje svým vlastním způsobem. Bohužel, jak již bylo zmíněno, špatná architektura  je technický dluh a zároveň je obrovským zdrojem dalšího nového technického dluhu.

Stejně jako byste měli mít vizi, jakým směrem se bude v určitém časovém horizontu ubírat váš produkt (viz článek Product Owner Survival Handbook), tak byste měli mít vizi toho, jaká bude architektura vašeho systému, datového modelů a UX. Slovo vize neznamená do kamene vytesaný design model, vize spíše definuje základní pilíře designu a sadu pravidel a principů, kterými se řídit při provádění jakýchkoliv změn aplikace.

Tyto principy by měli být sdíleny napříč celou společností, měli by být komunikovány na poradách ohledně architektury a jejich dodržování by mělo být kontrolováno při code review.

Kdo a jak vizi architektury vytváří? To je téma na samostatný článek, z velké části proto, že je to spíš problém dobré komunikace a schopnosti dohodnout se na společném plánu (viz článek Smysluplné porady a společné rozhodování).

 

#12 Pište testy, refaktorujte

Existence dobrých testů je základním předpokladem toho, že se nebudete bát refaktorovat (refaktoring kódu – změny architektury a designu zdrojového kódu bez úprav funkcionality). Mám praktickou zkušenost s týmem, který se na začátku svého fungování obával jakýchkoliv změn v datovém modelu, po určité době, kdy se disciplinovanou prací dostal do situace, kdy veškerá důležitá funkcionalita celé služby byla pokryta dobrými testy, změny v modelu včetně zásadních transformací byly rutinní prací, nad kterou se nikdo nepozastavoval. Význam testů je pro refektoring zásadní. Čím více jim můžete důvěřovat, to znamená čím více chybových stavů napříč celou aplikací zachytí, tím větších zásahů do systému budete schopni.

Psaní testů má i velký význam na jiné úrovni. Pokud máte problémy s psaním testů nebo pokud je jejich implementace krkolomná, pravděpodobně to signalizuje, že testovaný kód nemá dobrou architekturu nebo je plný technického dluhu.

 

red-green-refactor

 

Refaktoring jako takový by měl být součástí všech commitů. Tuto ideu nahlas vyslovil Leo Brodie v knize Thinking Forth (mimochodem pro mě osobně kniha natolik zásadní, že jsem po ní pojmenoval celý svůj projekt Think-Forth). Brodie dlouho před tím, než přišel agilní vývoj, vyslovil mnoho novátorských leč pragmatických ideí. Ekvivalent Beckova Red-Green-Refactor je jednou z nich. Jde o mentální model, ve kterém každou změnu kódu provádíme jako malou akci, která se pokusí co nejrychleji přidat požadované chování (přechod Red – Green), ale práce je skutečně hotova (commitnuta do repository) až poté, co je refaktorována. Jinými slovy napíšeme test, který nejdříve neprochází, protože daná funkce ještě není naimplementovaná, upravíme kód tak, aby test začal procházet. Jakmile test prochází refaktorujeme, tak aby naše změna byla kompatibilní s agreementy ohledně psaní kódu. Ze zkušenosti bych řekl, že většina lidí je schopna kód lépe refaktorovat pokud už existuje, než vymýšlet čistý a dokonalý kód rovnou.

A propos, víte, jak spolehlivě měřit míru technického dluhu ve vašem kódu?

 

wtf

 

Poslední, trošku punk myšlenka k zamyšlení, kterou na téma technického dluhu vyslovím je: netestovaný kód je technickým dluhem. Tak si o tom ve vašem týmu třeba popovídejte, může vás to dovést k zajímavé diskuzi.

Na závěr bych chtěl poděkovat všem, kteří přispěli svými vstupy k sepsání tohoto článku. Díky!

 

Working Effectively with Legacy Code

Bible práce s legacy kódem. Pokud válčíte s legacy kódem, tahle knížka vám nabídne praktické postupy na řešení konkrétních problémů.

Refactoring: Improving the Design of Existing Code

Stejně tak jako je Working Effectively with Legacy Code biblí práce s legacy systémy, tak Refactoring nastavuje pravidla refaktoringu existujícího kódu a vlastně i definuje, co refaktoring je.

Clean Code: A Handbook of Agile Software Craftsmanship

Toto je kniha, kterou jsem kdysi koupil všem vývojářům v Netsafe Solutions a kterou jsme si společně četli, jednotlivá témata pravidelně diskutovali a zaváděli je do naší práce se zdrojovým kódem. Dopad na kvalitu práce byl zásadní.

Thinking Forth

Perla z roku 1984. Přestože se jedná o knihu popisující programování v dnes už skoro zapomenutém jazyce Forth, její přesah je tak obrovský, že myšlenky a postupy v ní popsané se dají aplikovat téměř všude. Knihu bych ale nedoporučil úplným začátečníkům v oblasti vývoje software, na její čtení je dobré mít už určitý nadhled.

Advertisements

Zanechat Odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

WordPress.com Logo

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit / Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit / Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit / Změnit )

Google+ photo

Komentujete pomocí vašeho Google+ účtu. Odhlásit / Změnit )

Připojování k %s

%d bloggers like this: