Jaká jsou úskalí Quick-and-Dirty-Programming a jak se jim vyhnout? Část 2.

V předešlém článku jsme uvedli metodu Quick and Dirty Programming. Jak bylo trefně poznamenáno v komentáři od kolegy u předešlého článku, tak není až tak relevantní otázka, kdo se s ní potkal, ale naopak, spíše ať se přihlásí ten, kdo se s touto metodou nikdy nesetkal.

Kde hledat hlavní příčiny tolerance k nečistému kódu a kde je podstata tak časté preference této metody tvorby SW?

Samozřejmě v jednoduchém pohledu zde hraje roli tlak na termíny. Opravdu se může stát, že v projektu nastane situace, kdy termín doslova opravdu „hoří“ a zakázka při nedodržení deadline pak už vůbec nebude obchodně realizována. Jenže to bývá jen opravdu „někdy“ a je to důsledek jiných chyb v postupech v řízení projektu.

Spousta tlaků na termín však nastává v principu ze zavedení filosofie ve firmě už na počátku projektu: Při počátečních odhadech se dopředu počítá s metodou Quick and Dirty Programming jako se standardem. Zavádí se postup „chceme dělat hlavně a bezpodmínečně rychle a čistota kódu nás nezajímá“ – a tomu se podřizují další kroky. Ale to je již principiálně jiná situace, to už není nějaká krize: Zvažuje se totiž dopředu (nikoliv v kritické situaci), že tato metoda bude nasazena. Někdy to nastane vědomě, někdy nevědomky (nevědomky tehdy, když se o rozdílu tvořte kód kvalitně a nebo špinavě vůbec neví a neuvažuje se o něm).

Jednou z hlavních příčin zavedení metody Quick and Dirty Programming  je „optimisticky pojatá psychologická vize“ růžových optimistů vycházející z předpokladu, že katastrofa nikdy nenastane.

Uveďme si klasický příklad z teorie her:

Máte na výběr ze dvou možných hazardních her (podotknu, že obě dvě jsou pro vás dost nevýhodné). Důležité je, že budete tuto hru hrát nyní a pouze jednou, jen si musíte z těchto dvou strategií vybrat. O příštích hrách vůbec nevíte, zda a kdy se uskuteční. Dvě varianty dané hry jsou tyto:

První možná varianta: Na konci hry určitě přijdete o 500 Kč.

Druhá možná varianta: Bude se házet mincí (která není falešná) a pokud padne orel, přijdete o 1 000 Kč, pokud padne panna, tak nepřijdete o nic.

Kterou hru si vyberete?

Matematik vám řekne, že z hlediska teorie her je to jedno. V obou případech totiž statisticky vzato „v průměru“ přijdete o 500 Kč. Jenže první hra je psychologicky více deprimující a „beznadějná“. Spousta vizionářů (růžových optimistů) se raději přikloní k druhé variantě, protože „tam je aspoň trochu naděje, že se to nestane“. Dokonce, i kdyby byla druhá varianta trochu ztrátovější, stejně ji zvolí. Ale to už je psychologie a nikoliv matematika.

Právě v podstatě tohoto příkladu můžeme spatřit jeden z důvodů preference nečisté metody tvorby SW. Je to psychologicky optimistická vize: Problémy se odloží za cenu možného projevení později… a ty snad ani nenastanou, to je přece budoucnost.

Problém je v tom, že uvedený příklad je pouze matematický a jednoduchý příklad, který zohledňuje pouze „okamžitý korunový zisk resp. ztrátu“ v dané hře (v tomto příkladu pro názornost byl zvolen nerozhodný výsledek). Jenže v budoucnu se určitě projeví ještě další vedlejší efekty související s rozdílem mezi oběma strategiemi:

1. U druhé „riskantní“ hry, která v našem příkladu preferuje rychlé a nečisté programování, vzniká tzv. „technologický dluh systému“. Tento dluh bohužel neroste lineárně, ale spíše exponencionálně . Stará dobrá poučka návrhu SW říká: „Každá nečistota plodí další nečistoty“. Důsledkem toho nakonec může být stav, kdy „nečistý systém“ je nejenže hodně chybový, neflexibilní ale hlavně se z něj časem stává netransparentní molochální slepenec a práce na něm přechází v dost nepříjemnou detektivku.

2. Systém navržený Quick and Dirty postupem je chybový a špatně se testuje. Nutno podotknout, že zde se dá tento efekt tak trochu zmenšit jakýmsi částečným přechodem k variantě první hry s menšími náklady a to zavedením povinného Unit testování. Musí se však pro tuto činnost vyhradit odpovídající prostor a čas, protože i Unit testy něco stojí. Tyto nutné náklady na Unit testování jsou skvělým příkladem oné „stálé ztráty“ v první hře (ale jedná se o nutné náklady, které se jako takové určitě vyplatí).

3. Ztráta dobrého jména firmy. Vzhledem k tomu, že kvalita systému postupně a někdy i rychle klesá, zákazníci vyjadřují svou nespokojenost a někdy může dojít až ke katastrofickému jevu, kdy se systém stane natolik neudržitelným, že se zpočátku nadějný větší projekt prostě odhouká (viz například komentář u předešlého článku).

4. Není nad to, pokud na projektu pracují zapálení a nadšení vývojáři chtějící odvádět kvalitní práci. Zavedení filosofie tvorby Quick and Dirty je opravdu velmi dobrým zabijákem entusiasmu a profesního nadšení pro tvorbu SW. Neumím si představit horší příkaz, než „dělejte to rychle a špatně“. I když takto to nikdy od vedení nezazní, ale podstatou této filosofie to je. Pouze programátor cynik může psát vědomě nečistý kód bez skřípání zubů. Navíc (a to není zanedbatelné) v takovémto prostředí se vývojáři nestanou nikdy špičkovými profesionály, protože nebudou profesně růst (na to totiž není čas). Prioritou v metodě „rychle a nečistě“ je nějak „zbastlit“ systém a nikoliv se vzdělávat a odvádět kvalitní práci. Osobně toto považuji za nejhorší důsledek, protože záporné projevy se stávají principální a nevratné. Postup Quick and Dirty se stává zažitým obvyklým standardem…

Co s tím?

Samozřejmě nastává otázka, jak u takového vlaku přehodit výhybku. Bylo by příliš naivní se domnívat, že ve firmě někdy nastane ideální situace, kdy se bude tvořit pouze a jenom čistý kód. Ten nebude nikdy  stoprocentní Ale pokud je ve firmě zavedena filosofie Quick and Dirty obecně jako standard, musí se něco změnit. O tom bude další pokračování seriálu.

Poznámka nakonec: Přiznám se, že jsem kdysi vkládal velké naděje do postupu tvorby pomocí SCRUM resp. jiných agilních technik. Domníval jsem se (kdysi a mylně), že určitá míra „svobody“ tvorby napomůže v týmu lépe tvořit čistý kód. Jenže už první zkušenosti z projektů mi ukázaly, že tomu tak není. Dokonce naopak, u mnoha projektů tvořených pomocí SCRUM jsem se tak setkal s opravdu ukázkovými příklady programátorských paskvilů. Zmíněná „svoboda tvorby“ se mnohdy projevila dost častým ignorováním návrhu čistého kódu včetně opomíjení kvalitní počáteční analýzy. Díky tomu ve firmě mnohdy nastal zpětný pád do chaotické metody tvorby SW.

Navíc jsem u agilních technik (SCRUMu) vypozoroval jednu dost zajímavou paradoxní skutečnost.

zdroj obrázku
https://blogs.deusto.es/master-informatica/kanban-agile-planning-with-burn-down-chart/

Hovoří se sice o “svobodě”, ale technika plánování pomocí Burndown Charts se může vůči programátorům chovat jako opravdu velmi kvalitně upletený bič a může na vývojáře vytvořit tak silný tlak , že se nakonec díky tomuto tlaku uchýlí k technice Quick and Dirty.

Pokračování následuje.