Přejít k navigační liště

Zdroják » Různé » Technický dluh

Technický dluh

Články Různé

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.

Komentáře

Subscribe
Upozornit na
guest
23 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Oldřich Vetešník

Hezké, díky za článek. :) Bohužel mám zkušenost až tak děsivou, že ten kód, se kterým jsem se setkal, byl už tak špatný, že nejen že se kdokoliv bál tam cokoliv dělat, ale ani ty testy na to nešly napsat. Takovou tu nálepku „dobrý kód = drahý kód“ nejspíš dostal v momentě, kdy si někdo řekl „dost“, a do špatného kódu udělal něco dobře.

Poznámka: Je tam asi typo ve větě „Platí vás tvrdou skutečnými penězi“.

JakubTesarek

Díky, to je dobrý postřeh. Co dělat s kódem, který už je v tak otřesném stavu, že s ním nikdo nechce mít nic společného jsem schválně nerozebíral. Článek by byl příliš obsáhlý. Pokud by tě to zajímalo, tak na příští Poslední sobotě o tom budu přednášet. Budu moc rád když se přijdeš podívat, můžeme o tom klidně potom hodit řeč.

shady

co ti, ktori sa nebudu moct dostavit ?
co tak dalsi clanok ? :)

co znamena „Rozlučková“ ? http://srazy.info/posledni-sobota/4160

JakubTesarek

Pro ty, kteří se nebudou moci dostavit chystáme záznam. Z materiálů, které se mi do přednášky nevejdou buď sepíšu nějaký další článek a nebo vytvořím videa na youtube :-)

A rozlučková je proto, že David Grudl oznámil, že končí s vývojem Nette.

dmatej

Já říkávám, že permanentně „utíkáme exekutorovi z lopaty“. Musím o tom něco sepsat, myslím, že už jsme tak říkajíc evolučně vyvinuli slušné strategie, jak se s tou železnou koulí na noze posouvat směrem ke kvalitě.
Když se chce, tak to jde, jen si musíte zahrát na „rytíře“, který ví, co dělá, nesejde z cesty, a nenechá se „zlákat ďáblem“. Jinak řečeno, cokoliv nového musí být napsáno dobře, neexistuje „dolepování“.
To je na tom nejtěžší, odpadla už spousta lidí, kteří nakonec podlehli a přizpůsobili svoje psaní tomu, co bylo kolem a do špaget nastrkali ještě drátky (a jiní nitě). Projekt je zahubil strašlivou smrtí!
Testy psát vždycky nejde, protože pokud máte 3000 řádkovou metodu (automat!), první věc, kterou při refaktoringu uděláte, je, že budete muset přepsat testy. Někdy se ale i takové testy napsat stejně hodí …

Zkrátka, je tam spousta nuancí, zkoumání slepých uliček, práce pyrotechnika, hodináře, leckdy naopak kopáče s krumpáčem a lopatou, to když víte, že z těch 1000 řádek je kopií jiných 1000 řádek a stačí vám dva parametry, abyste žádnou kopii nepotřebovali …

Ani neočekávejte, že to bude bez chyb. Ale je třeba je minimalizovat – a nakonec opravit.

P.S.: Naše aplikace má kolem 500 000 řádek kódu jen v javovské části – od roku 2007 dělá tak 5x víc věcí, ale počet řádek nevzrostl snad ani o 5%.

MarianSchubert

Pokud clovek pracuje s tak spatnym kodem, tak doporucuji knizku „Working Effectively with Legacy Code“. Bezpecne zmeny lze provadet i v extremne spatneho kodu relativne jednoduse.

shady

jj, si pamatam ze vytiahnut cas kodu v ktorom chcem robit zmeny von, spravit na to testy, a potom v nom robit zmeny

Oldřich Vetešník

Už jsem o tom slyšel, zkusím se na to podívat, díky. :-)

Tomas Voslar

Vsadim se, ze vim v jake firme jsi tohle zazil :))

Oldřich Vetešník

Hahaha :D, jo no, naštěstí už jsem jinde. Ne že by se to nějak nedalo, to jen ta kupa hnoje je prostě tak strašně velká, že jeden člověk na to nestačí. A ani toho by nikdo nezaplatil. :(

sachy

On ten kód nemusí být děsivý „by design“, ale prostě 2x starší než průměr věku vývojářů, časem se samozřejmě dokoupily a integrovaly externi moduly/produkty. Pak učící křivka vypadá jak rampa pro kočárky a tak se vesele bastlí protože deadline…

patriksima

Asi by se mělo definovat co je „děsivý“. Protože někoho děsí v html použití značky místo , a přitom to není nic proti ničemu. Takže u některých věci je to pohled od pohledu.

patriksima
  • značky B místo značky STRONG
dmatej

Ano, programátoři často řvou, že „je to děsně předpotopní kód“, ale – věk kódu nic s čistotou ani udržovatelností nemá společného. Znám lidi, kteří dělali v Cobolu nebo assembleru – zatraceně dobře ví, co je udržovatelnost.

Myslím si, že v podstatě je to všechno pořád o jednom – schopnosti určit hranice (tj. dovnitř patří to, co všechno potřebuji, aby to udělalo, co má, ven pak patří všechno ostatní, zbytek jsoucna :-) ) a pak definovat rozhraní, pokud možno co nejjednoznačněji (potřebné zdroje, parametry, výstupy, důsledky, možné chyby).

S bastlením se dá kdykoliv přestat, ať mi věříte, nebo ne, nikdy to není dražší. Panika je naopak drahá vždycky – a lajdáctví nebezpečné.

Oldřich Vetešník

Ne že bych assembler uměl, spíš jsem si ho vyzkoušel, ale cosi mi říká, že by bylo fajn, kdyby každej programátor dostal nějakej úkol v tom napsat a chvíli udržovat, jestli by ho to nedonutilo psát líp.

fish

V podstate vytah ze skvele knihy „Cisty kod“, kterou by si mel precist kazdy programator. Ale i tak diky za strucny vytah ;)

patriksima

Já to vidím tak, že každý nový programátor by to udělal líp než ten předchozí. A výsledkem je mnoho práce a málo muziky.

Málokdo píše testy a dokumentaci jednoduše proto, že si neumí stanovit správnou cenu. A pak se jim to tam prostě „nevleze“.

Sekundární problém je v nesprávné komunikaci. Soft-skills jsou obecně problémem tohoto odvětví.

dmatej

S prvním odstavečkem nesouhlasím, resp. ano, chápu, jak to myslíte a je na tom kousek pravdy, ale mezi řádky je to spíš trochu příznak bezradnosti. Jedna věc jsou „tlučhubové“, což jsme asi skoro všichni, a druhá věc je konstruktivní pohled, který dnes lidi (nejen programátoři) moc neumí: Co je na tom špatně? Jak by to mělo být dobře? Kolik práce to bude? – a pak je na řadě zvážit, jestli to stojí za to (dá se stihnout, resp. závisí na tom další rozvoj). Přitom jako u všeho je třeba počítat s tím, že se to může zkomplikovat, např. že se nakonec ukáže, že původní řešení bylo hnusné, ale 1000x rychlejší (proč?), atd.

Druhý odstaveček je pravdivý – nicméně dokud to není, není to hotové. Tečka. I kdyby měl být přesčas, i kdyby PM musel obhajovat tým u šéfů. U nás jsem trochu ve výhodě – šéfové už se spálili.

Třetí je také trefný – nikdo nejsme dokonalý, nejhorší je ale rezignace na komunikaci.

arron

O bývá často také problém na straně těch manažerů, kteří chtějí po programátorech věci, které neumí. Například odhadování náročnosti. To, co řekne programátor je v drtivé většině případů nutné vynásobit minimálně dvěma :-) Spíš ale dvěma a půl, někdy i víc.

A na druhou stranu, manažer by si naopak měl uvědomovat, že projekt nějakou dobu poběží a bude potřeba ho udržovat a sám by měl programátory tlačit do toho, aby ta údržba byla v budoucnu co nejjednodušší a daly se na tom vyvařit nějaké peníze. Krom toho s čistým kódem a testy roste přímo úměrně spokojenost klienta (když nic jiného, tak méně bugů) :-)

Jirka

Odhadování pracnosti je schopnost, kterou by se měl programátor naučit. A jde to, pokud se dokáže poučit z předchozího odhadu a skutečného odpracovaného času (např. ten dvojnásobek :-) ).

Odhadování by podle mě měl dělat právě vývojář, protože je ten jediný, kdo má technickou představu o daném požadavku a o zbytku systému. PM nebo zkušenější kolega ho může korigovat, dávat mu vhodné otázky jestli na něco nezapomněl, ale odhad by měl sestavit ten, kdo to bude programovat.

Pavel Bina

Znám a vím, a pokud manažer ví, že ti před tím nebyli úplní chlíváci, neměl by svolit.

Petr

Refaktoring znamená změna. Změna znamená možné zanesení chyby. Chyba stojí peníze a hledá se viník. Takže se do refaktoringu nikdo nepouští, pokud není už vyloženě v úzkých.

Ale… není to nakonec dobře? Totiž je zbytečné čistit kód ad absurdum. Stojí to peníze a zákazníkovi to stejně nic nepřinese.

bodo

Spravne. Nemali by sme cistit ani zachod, stoji to peniaze a nikomu to nic neprinesie, zachod nezmeni svoj tvar ani nezlepsi svoju funkciu.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.