Paralýza bez analýzy

Kašleme na ně, radši vyhyneme!

Je známým faktem, že tzv. „antipatterny“ si lidé pamatují snáze než „patterny“, čili vzory. Týká se to i pojmu „Analysis-Paralysis“ (analýza-paralýza), nebo naopak „Extinct by Instinct“ (vyhynutí instinktem). Přitom spousta vývojářů už někdy slyšela o dokumentech, kterým se říká „detailní návrh systému“, „specifikace požadavků“, UML diagramy, „use case“, „popisu chování“, … atd.

Typický vývojář se hrozně těší, až si do svého výtvoru prvně klikne myší, pošle mu zprávu a v ideálním případě dokonce dostane odpověď, až to zkrátka konečně začne něco dělat. A tak se vykašle na analýzy a dokumentaci, a začne bastlit, během čehož si teprve začne uvědomovat, co všechno ještě bude muset přidat, předělat, průběžně upravit svoje původní nápady, ale zároveň nerad maže to, co už udělal.

A když už to má všechno za sebou, nenávidí opravování chyb, a za nic na světě nezačne psát automatické testy – čím jsou náročnější, tím větší je odpor. A náročnější jsou tím víc, čím složitější je implementace i rozhraní, i čím složitější je popis chování aplikace.

No počkat, „popis chování aplikace“? Ten ale neexistuje, jeho jediná instance je ve vývojářově hlavě, a permanentně se mění, nakonec dojde ke vzpouře mysli, která ve výsledku začne prosazovat chyby jako chtěné vlastnosti. Vývojář se hrubou silou pokusí protlačit svůj mizerný geniální výtvor přes jakákoliv akceptační pravidla týmu, šéfů, zákazníka, kohokoliv, jen aby to měl za sebou.

Kolikrát se tohle zopakuje, než vývojář „vyhoří“?

Kolikrát se tohle zopakuje, než s ním tým ztratí trpělivost?

Kolikrát se tohle zopakuje, v kolika týmech, u kolika zaměstnavatelů, u kolika zákazníků?

Mockrát.

Zákazník si zvykne a bojí se, že po utracených milionech to jinde bude zase stejné.

Zaměstnavatel má problém sehnat jakéhokoliv vývojáře, snaží se udržet si i ty špatné.

Nejmocnější je podle mého soudu tým samotný, dobrý tým se musí nutně zbavovat členů, kteří mu kazí pověst i dílo, bez ohledu na to, že takovými změnami přidělává práci personalistům firmy i svým šéfům. Samozřejmě to je až krajní stav, kdy dotyčného nelze proškolit, kdy se nedokáže sžít s fungováním kvalitního týmu. Naopak pokud není kvalitní tým jako celek a nelze z něj přiměřeným úsilím kvalitní tým učinit, není důvod v něm setrvávat.

Žádné násilí ale není nutné.

Někteří vývojáři dokonce tvrdí, že je vysoká škola nic nenaučila. Zapomínají, co všechno se jim dostalo do podvědomí, přestože si nepamatují podrobnosti. Přehlížejí, že je škola naučila se nejen učit, ale i zapomínat nepotřebné detaily, vybírat jen to podstatné a detaily vyhledávat a chápat. Schválně, víte nebo aspoň tušíte, o čem je řeč? Jak často si na to vzpomenete při vývoji?

• O(n)
• B-tree
• SHL, SHR
• BCNF
• Transformační matice
• Konečný automat
• Spolehlivost systému
• Korelace jevů
• Riemannův integrál
• Svobodovy mapy
• Násobení matic
• Rekurze
• Podmínka nutná, nikoliv postačující.
• …

Vývojáři rádi vyvíjejí, vynalézají, ale často neradi zapisují myšlenky a ověřují je, hledají souvislosti. K tomu musí časem dospět, obvykle s trochou donucení kvalitním týmem. Ano, kvalitní tým píše dokumentaci a píše analýzy – ne však protože je někdo vyžaduje, ale protože jsou užitečné!

Jak překonat odpor

Jak? Sněním. Už máte něco za sebou, tak si vzpomeňte, jak jste se v tom programování ztráceli minule. A co všechno jste už mohli vědět předem, kdybyste si dali tu práci. Ne, nepotřebujete začínat UML diagramy a těmi obrázky, které vám vnutili ve škole. Začněte smluvním popisem, který proberete se zadavatelem – nemusíte hned psát knihu, stačí sepsat si na papír co víte, a co byste chtěli vědět:

• co aplikace má dělat
• co aplikace nemá dělat (hodí se vytyčit „hranice“, odkázat se na související funkcionality)
• jakým způsobem bude interagovat s klientem (browser, ws, db, ...)
• kdo je klientem (server, člověk, jiná aplikace, …)
• kolik je klientů (jeden? tisíc? lze počet regulovat? jak?)
• jaký bude mechanismus kontroly oprávnění, co vše bude zohledňovat?
• pokud jde o uživatelské rozhraní, jak bude vypadat, jak se bude chovat (co bude na formuláři, co se stane, když uživatel klikne sem nebo tam, má mu textové pole napovídat a jak?)

Pak pokračujte o něco blíž programování ...

• jaký bude vliv na zátěž HW, nároky na disk, paměť, sítě?
• alternativy technologií i přístupů
• rizika – kde se dá očekávat problém? Dá se předejít prototypováním, matematickým modelováním, sběrem a statistickou analýzou dat?

Po pravdě taky se mi nechce psát analýzy, ale chuť se dá vylepšit právě prototypováním (něco naprogramujete, ale pak to vyhodíte, jen si zkusíte nějakou cestu) a i samotným faktem, že z napsané analýzy se všemi těmi nápady kolem má její autor mnohem lepší pocit, už protože ho navštívila řada dalších nápadů a inspirací, co s čím souvisí a jak by to asi mohlo být dobře.

Pravda, tu chuť obvykle trochu pokazí zákazník nebo kolegové-oponenti, ale po pár iteracích mají nakonec lepší pocit všichni a těší se, až to uvidí „žít“.

Dvakrát měř, jednou řež

Pozitivní je též to, že už se obvykle nezmýlíte v odhadu pracnosti řádově, byť tento odhad obvykle všechny šokuje, nakonec se ho dokonce možná i podaří dodržet, což je známka profesionality – samozřejmě se objeví také nápady, co seškrtat nebo odložit.

Při vývoji software není tolik důležitý materiál, o to důležitější je ale čas, který se velmi špatně odhaduje. Pro vysoké odhady obvykle nemá zákazník pochopení, na druhou stranu se rozhodně nevyplatí mu lhát a dávat mu jakkoliv optimistický odhad. Mnohem lepší je dát odhad spíše pesimistický a později třeba i zákazníkovi nabídnout slevu (což se ovšem málokdy stává, dělá to ale výborný dojem). 

Ošizením analýzy nebo interních testů a kontrol se také nic získat nedá, naopak dodáním „milestone“ verze k otestování zákazníkem nebo dokonce zatažením zákazníka do testování aplikace se dá vyhnout spoustě nedorozumění i problémů při akceptaci.

Tím spíš je pro obě strany dobré mít vše „na papíře“ - nikdy by pak neměl nastat stav, kdy zákazník dluží dodavateli několik milionů za vývoj aplikace, které odmítá zaplatit s tím, že půl roku o dodavateli neslyšel a nakonec se dodavatel pokusil předat něco, co není zákazníkovi k ničemu.

Interní (hlavně automatické) testy a kontroly však rozhodně neslouží k náhradě zákazníka, nýbrž k pokrytí celé řady cílů. Zákazník téměř nikdy netestuje aplikaci kompletně, ale spíše ověřuje, jestli plní jeho očekávání. Při tomto ověřování může dojít i ke změně požadavků zákazníka a prodražení aplikace – následovat musí dohoda, jak bude změna financována a jak je velká oproti stávajícímu zadání.

Automatické testy naopak pokrývají na různých úrovních:

• zafixování již implementovaného chování
• otestování funkcionalit, které testera napadly, nicméně není žádná záruka, že na ně narazí při ověřování zákazník (!)
• otestování hraničních případů
• otestování různých uživatelských scénářů

Z toho celkem jasně vyplývá, že část pokrytí kódu testy je nutně duplicitní – a přitom je velmi obtížné dosáhnout pokrytí 100%. Ten háček je ovšem v tom, že klíčové není pokrytí kódu testy, nýbrž pokrytí všech možných (tj. i velmi nepravděpodobných) scénářů včetně chybových. Vypočtené pokrytí kódu testy je jen pomůcka, protože žádný software nikdy nedokáže posoudit, jaký rejstřík kombinací stavů a událostí vůbec může nastat, natož které jsou vlastně důležité. 

Ve výsledku tudíž není až tak důležité procento pokrytí, mnohem důležitější je procento nepokrytého kódu, tj. kódu, přes který žádný automatický test ze všech sad vůbec neprošel. Není zrovna tam chyba? Dělá to to, co chcete?

Samozřejmě ani naopak pokrytí kódu testy neříká, že pokrytý kód je správně – pouze to, že nějaký test tudy prošel. Znovu tudy opakuji, pokrytí kódu testy jsou jen pomůcka; podmínka nutná, nikoliv postačující.

Proč jsem sklouzl k testům?

Protože první testy nelze psát na základě ničeho jiného než je nějaká forma analýzy, obzvlášť u přístupu „test driven development“, alespoň pokud chcete minimalizovat psaní zbytečného kódu i testů, které později zahodíte nebo v horším případě neužitečně ponecháte v aplikaci, čímž pro změnu prodražíte budoucí údržbu.

Prostě to udělejte dobře – a ne, tohle vážně není Vodopádový model vývoje, vše se dělá iterativně. Už na začátku je ale dobré mít alespoň hrubou představu, co že to vlastně vyvíjíte, a během chvíle doženete „rychlíky“, kteří se řídí instinktem, díky kterému se ale brzy začnou točit v kruhu. 

 

Myslíte, že ne?

P.S.: Příště už radši něco praktického ... ;)