Technický dluh

Každý kdo nějakou dobu programuje, to už nejspíš zažil – v kódu je absolutní chaos, úpravy trvají déle, než kdo předpokládal, noví programátoři se zaučují čtvrt roku, a když už se konečně podaří něco dokončit, tak je to samá chyba.

Technický dluh vzniká stejně jako jakýkoli jiný dluh – když žijete nad poměry a využíváte více, než kolik máte k dispozici. Občas je to ku prospěchu věci – půjčíte si třeba na rozjezd firmy nebo na školné. To jsou věci, do kterých můžete investovat víc prostředků, než máte, protože díky nim vyděláte víc a budete moci dluh splatit.

Technický dluh může být stejně legitimní. Celou kariéru se pohybuji kolem e-commerce, a tak už jsem si zvykl, že v předvánoční době se spouští spousta různých reklamních akcí – slevové kupony, reklamní bannery, doprava zdarma při nákupu nad XXX Kč, sleva 10% pro všechny zákazníky, kteří se přihlásí k odběru newsletterů a podobně. Takové věci chce mít management spuštěné pokud možno hned, protože každou minutou přichází o peníze.

Máte v podstatě dvě možnosti – napsat to velmi „slušně“ včetně testů, code review, doplnit dokumentaci, refaktorovat do znovupoužitelné podoby anebo to jednoduše nabouchat tak, aby to fungovalo.

Udělat v takovéto situaci dluh je naprosto v pořádku. Musíte ale počítat s tím, že technický dluh budete muset dřív nebo později zaplatit. Neexistuje způsob, jak se placení vyhnout. A čím déle budete splacení odkládat, tím bude dluh větší.

A nejsou to jen Vánoce – již několikrát jsem se ocitl v situaci, kdy na včasném dokončení i třeba jen hrubých prací závisela velká dohoda s partnerem. Když jsem pracoval v Shoptetu, oslovila nás společnost Allegro provozující portál Aukro s nabídkou, že nás zapojí do velké reklamní kampaně, pokud do určitého data napojíme všechny naše eshopy na jejich API. Zkuste v takové situaci vysvětlit majiteli firmy, že spolupráci musí odmítnout, protože byste nestihli dopsat dokumentaci nebo vše pořádně otestovat. Klidně to udělejte, ale když už v tom budete, nezapomeňte aktualizovat svůj životopis, může se to hodit.

Problémy přichází v okamžiku, kdy si musíte půjčovat na běžný provoz. Pokud nezvládáte standardní vývoj, aniž byste vytvářeli technický dluh, bude se kvalita vašeho kódu neustále zhoršovat. A jednou dojdete do bodu, kdy budete muset vše přepsat, začít znovu a opakovat stejné chyby anebo vývoj zastavit a věnovat spoustu času refaktoringu.

Mám pro vás tři tipy, které vám mohou pomoci technický dluh minimalizovat nebo jej alespoň udržet pod kontrolou.

Dokumentujte

Pokud už technický dluh vznikne, zdokumentujte ho a určete, do kdy má být splacen. Jednou z možností, jak to udělat, která je u vývojářů velmi oblíbená, je anotace TODO v kódu. Tento způsob je sice oblíbený, ale je to, jako byste neudělali nic.

Zaprvé, na to, abyste si takové poznámky všimli, musíte se jít na danou část kódu podívat. A na kód se většinou chodíme dívat, až když je s ním nějaký problém, což bývá dost pozdě. (Pokud anotace exportujete do externího nástroje, který vám z nich automaticky zakládá tasky, gratuluji, nejspíš víte, co děláte.)

Druhou stejně velkou nevýhodu je, že tuto informaci nemá k dispozici management. Pokud neděláte v nějaké hippie společnosti, bude na vás management vždy hrnout víc práce, než kolik by vám vyhovovalo. I kdyby zbytek firmy neměl do čeho píchnout, programátoři budou v záklonu.

Pokud už musíte vytvořit technický dluh, dejte si záležet na tom, abyste management obeznámili s tím, kolik je bude daná feature stát teď a kolik za měsíc nebo za rok. „Jistě pane Reynholme, ty slevové kupony můžeme spustit již tento týden, ale bude třeba investovat další týden během příštího měsíce. Během té doby nebudeme schopní pracovat na ničem jiném.“

Víte co se stane, když tohle řeknete šéfovi? Vůbec nic. Bude rád, že bude mít slevové kupony pro zákazníky během tohoto týdne. A ten další týden běh následujícího měsíce? Na ten s klidem zapomene. Musíte to někam napsat! Pokud máte frontu požadavků, hned na začátek založte task na refaktoring slevových kuponů, se kterým nepůjde hnout. A pokud takovou frontu nemáte, tak ji založte.

Nemáte právo jít za nadřízeným s požadavkem na investici času a tedy peněz na refaktoring. Je vaše práce mít kód v pořádku. Jen těžko budete takovou investici obhajovat „No víte, během minulého roku jste chtěl mít spoustu věcí rychle hotových, takže jsme něco museli tak trochu odfláknout a teď bychom jako potřebovali čas, abychom to po sobě jako opravili.“ Váš šéf nebo zákazník nebo kdokoli, kdo vám zadává práci, není věštec. Platí vás tvrdou skutečnými penězi, takže očekává skutečnou práci. Je v pořádku udělat si technický dluh, když přesně víte, kdy a jak bude splacen. A musí to vědět taky ten, z jehož kapsy to budete platit.

Určete zodpovědnosti

Až příliš často jsem slyšel, že kvalitu kódu lze dobře udržet přidělením zodpovědné osoby ke každému modulu, třídě, funkci nebo jakémukoli jinému kusu kódu. Většinou to funguje tak, že autor modulu je také zodpovědný za jeho další údržbu a rozšiřování. Když chce jiný vývojář do modulu zasáhnout, musí se poradit s autorem, který za kvalitu kódu zodpovídá.

Nejen že je to k ničemu, ale dokonce to kvalitu kódu velmi sráží.

Vývojáři přicházejí a odcházejí. Je velmi nepravděpodobné, že právě teď pracujete s vývojáři, kteří s vámi budou dělat i za deset let, budou dělat na stále stejném projektu, na stejné pozici a se stále stejnými technologiemi, nikdy neonemocní a nikdy si nevezmou dovolenou. Je tedy nesmysl spoléhat na to, že budou schopní navěky udržovat kód, který vytvořili.

Tento přístup nejen bojkotuje jakoukoli zastupitelnost v týmu ale je také příčinou nekvalitního kódu a technického dluhu. Pokud vývojář ví, že do jeho kódu nebude nikdo šťourat bez toho, aby se ho zeptal, může si dovolit dělat zkratky a „prasit“. Vždyť on sám ví, co kód dělá a může mu být jedno, že se v tom nikdo nevyzná, až z firmy odejde.

Vy naopak potřebujete v týmu vybudovat kulturu zodpovědnosti, kdy je každý vývojář zodpovědný za veškerý kód, se kterým přichází do styku. Ne nadarmo si většina vývojářů chválí kvalitu kódu, který vznikne v rámci párového programování. Když za kód zodpovídají dva lidé, jeden druhému nedovolí žádné zkratky, s kódem musí souhlasit oba.

Nejlepší obranou proti nekvalitnímu kódu je téměř bezohledná kontrola ostatními vývojáři, kdy všichni zodpovídají za vše. Zkuste commitnout spaghetti kód do repositáře Nette. Ne David jakožto otec Nette, ale ostatní vývojáři vás vypískají. To oni Nette denně používají a s vaším spaghetti kódem nechtějí pracovat. Takovou kulturu ve firmě potřebujete. Funguje to. Když jsem přebíral pozici vedoucího vývoje v Shoptetu, takovou kulturu jsem se pokusil zavést. Samozřejmě se tím najednou nevyřešily všechny problémy, které v kódu byly a nejsou vyřešené ani teď po dvou letech. Od té doby se ale kvalita kódu kontinuálně zlepšovala. A věřím, že se zlepšuje i teď, když tam už nepracuji. Povzbuzujte své kolegy, aby se nebáli „říznout“ do cizího kódu. Koneckonců, máte unit testy a repositář. Když se něco pokazí, hned se to dozvíte a máte možnost změny hned vrátit zpět. A pokud ne, máte o důvod víc si je pořídit.

Přestaňte technický dluh vytvářet

Když jsem se začal zabývat kvalitou kódu, rozčilovalo mě, jak dlouho trvá něco naprogramovat. V zásadě jsem viděl dvě možnosti, jak vytvářet čistý kód:

  1. Psát kód od prvního řádku co nejčistěji – nad každou proměnnou se zastavit a promyslet její název, u každého příkazu se zamyslet, jestli neporušuje některé z pravidel solid, spočítat cyklometrickou komplexitu atd. Bylo to pomalé a navíc jsem se pro všechen ten čistý kód nedokázal soustředit na problém, který jsem měl vyřešit.
  2. Druhou možností bylo psát kód tak, jak jsem byl zvyklý, a po každém dokončeném úkolu refaktorovat jako o život. Tak jsem více než polovinu času strávil na něčem, co bylo z mého pohledu neproduktivní (z pohledu mého nadřízeného taky).

Mám takovou jednu vlastnost – když nevím, tak se zeptám. Tak jsem napsal Robertu Martinovi a zeptal se ho, jak přesvědčit programátory a sám sebe, že má smysl psát čistý kód, když to stojí tolik času, ale ta investice se vrátí až za dlouho.

Tohle mi odpověděl:

BKEMj_-CYAA6kh6

„To je ale blbost“, řekl jsem si. Postupem času se ale ukázalo, že měl pravdu. Nemusíme psát špatný kód.

Psaní čistého kódu je skill jako každý jiný. Když jste prvně řídili auto, nejspíš jste také museli přemýšlet, kde jsou pedály a před každou křižovatkou vymyslet, jak jí projet a nezabít se. Časem se z toho stala rutina.

Stejně tak se můžete naučit psát čistý kód. Pak už nebude ani v největším náporu práce muset vytvářet technický dluh, protože cleancode pro vás bude přirozený. Třeba někdy nebude čas psát skvěle znovupoužitelný kód, ale tím, že pro vás bude psaní čistého kódu rutina, budete umět lépe odhadnout, co je třeba napsat robustněji a co bude lepší v případě potřeby vyměnit.

Každou sobotu se snažím vývojářům říci něco zajímavého o čistém kódu. Je to skvělý způsob, jak se něco nového přiučit – já se díky tomu učím pořád. Pojďte to taky zkusit.

Jakub Tesárek je programátor který se rozhodl, že už bylo dost špagetového kódu a že to tak nenechá. Přednáší, školí, natáčí videa a jak vidíte, tak i píše o čistém kódu a co dělat, aby čistý byl.

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 23

Přehled komentářů

Oldřich Vetešník
JakubTesarek Re:
shady Re:
JakubTesarek Re:
dmatej Re: Otřesný kód
MarianSchubert Re:
shady Re:
Oldřich Vetešník Re:
Tomas Voslar Re:
Oldřich Vetešník Re:
sachy Děsivý kod
patriksima Re: Děsivý kod
patriksima Re: Děsivý kod
dmatej Re: Děsivý kod
Oldřich Vetešník Re: Děsivý kod
fish Cisty kod
patriksima Zkušenost manažera
dmatej Re: Zkušenost manažera
arron Re: Zkušenost manažera
Jirka Re: Zkušenost manažera
Pavel Bina Re: Zkušenost manažera
Petr A není vlastně lehce špinavý kód správně?
bodo Re: A není vlastně lehce špinavý kód správně?
Zdroj: https://www.zdrojak.cz/?p=10965