O softwarové kvalitě již bylo napsáno mnoho knih i článků. V konzultačních firmách nalezneme celá oddělení řešící právě jen tuto oblast. Paradoxně je ale kvalita stále tím největším „otloukánkem“ v rámci SW procesu. Přestože všichni podvědomě tušíme, že se její opomenutí nevyplatí, stejně se mnohdy rozhodneme pro (alespoň většinou) finančně obhajitelnou zkratku, při které kvalita značně utrpí.

Pokud se bavíme o standardním projektovém trojúhelníku, není většinou problém zdůvodnit dopady nedostatku času, zdrojů nebo naopak bobtnání rozsahu. S kvalitou je ale tak nějak obecně problém. Proč bychom vlastně nemohli obsah našeho trojúhelníka zmenšit? Vždyť bychom například mohli s menšími náklady při shodném počtu zdrojů dodat shodný rozsah, že?

Z pohledu softwarového inženýra se jedná o naprosto chybný předpoklad, který dle všech pravidel softwarového inženýrství nemůže fungovat. Z pohledu business vlastníka však dotaz reflektuje čistě racionální uvažování někoho, kdo vládne rozpočtem a chce vědět, co za své peníze vlastně dostane navíc.

A tady nastává jeden z problémů spojených se softwarovou kvalitou. Většina zkušených inženýrů začne na výše uvedenou otázku reagovat specifickými metrikami a důvody, proč je kvalita důležitá. Například vypíchnou důležitost jednotkových testů, statické analýzy, ukáží pár metrik, zdůrazní čitelnost kódu, udržovatelnost, menší počet chyb v produkci a s nimi spojené nižší náklady na opravy, atd.

Vše výše uvedené je samozřejmě pravda, ale lze předložit jasnou a neprůstřelnou statistiku, která business přesvědčí? Naneštěstí velmi zřídka. Náš obor je specifický tím, že většina software je svým způsobem unikátní pro konkrétního zákazníka. Nelze tedy jednoduše ukázat, že tým A k projektu přistoupil takto a tým B takto, a tedy po X měsících vývoje máme jasné statistiky, který přístup byl lepší. K dispozici máme pouze příklady odjinud, nicméně i tam se můžeme velmi často dostat do diskuze na téma „co by/kdyby“.

Softwarovou kvalitu lze úspěšně přirovnat k základním hygienickým nárokům. Mytí rukou vám nikdy 100% nezaručí, že neonemocníte Hepatitidou A, nicméně velmi významně tím snížíte šanci (ale ano, budou existovat i lidé, kteří se nemyjí vůbec a neonemocní). Obdobné platí i u nároků na operační nástroje, které musí být před zákrokem vždy desinfikované, jinak hrozí vážná infekce. I zde najdeme příklady, kdy se tak nestalo a žádné komplikace nenastaly. Nicméně od doby, co toto pravidlo platí, se úmrtnost pacientů rapidně snížila.

Předchozí příklady jsou zvoleny účelově, jelikož v daném kontextu nám přijde potřeba „základní hygieny“ naprosto zřejmá a jinou alternativu ani nepřipouštíme – zde jde o lidský život. V případě software by to ale mělo být podobné – jde o život daného softwarového produktu, v důsledku pak i o budoucnost jednotlivých členů týmu, z business pohledu o nic menšího než o peníze.

Jenže daří se nám přesvědčit zadavatele o tom, že vysoké pokrytí jednotkovými testy, použití continuous integration a nebo minimum nálezů z nástrojů typu SonarQube je ta naprosto nezbytná hygiena? Kéž by! I přes absenci testů a chybějící dokumentaci se přeci software povede sestavit a provozovat, a hlavně prodat zákazníkům (ať už interním nebo externím). Kde je tedy problém? Přístup funguje, business case se plní. Prostě: „Pojďme tedy proces zopakovat ještě jednou! Kdo by se staral o kvalitu“.

Předchozí způsob vývoje je častým v případech, kdy se firma/tým snaží co nejrychleji zasáhnout trh a čas je tedy kritická veličina. Hlavně ať jsou k dispozici výsledky, pak můžeme řešit následky. Pokud by byly problémy opravdu řešeny, dal by se možná tento přístup částečně tolerovat. Zpravidla však k narovnání stavu nikdy nedojde a proces se pak zopakuje znovu a znovu a znovu a tak dále.

Stejně, jako byl krátký čas vzniku software kritický pro tým na začátku projektu, stává se delší čas údržby pro celý tým fatálním v jeho pozdějších fázích. Přichází nové požadavky, ale ty jsou stále těžší a těžší na realizaci, protože nezapadají do celkové architektury – velmi často proto, že žádná pořádná architektura neexistuje a nebo není dodržována (nebyl čas…). Vše se dělá ručně, každá změna kódu může spustit dominový efekt, kód se tedy raději nemění, ale duplikuje. Místo vyřešení jednoho problému se tedy zakládá jiný potenciální problém, až bude nutné zkopírovanou funkcionalitu opravit ve všech výskytech, atd. Pokud i zadavatel dospěje do stádia, kdy chce kvalitu začít řešit (konečně!), zpravidla požaduje rychlé řešení ve stylu Paretova pravidla (za minimum úsilí maximální dopady). Požaduje tedy identifikaci jednoho zdroje všech problémů a následnou rychlou nápravu. Problémy však často nemají jeden konkrétní zdroj, který je možné rychle eliminovat, ale typicky se jedná o souběh více obtíží a překážek, které problémy generují. Tím hlavním problémem je totiž celková kvalita řešení, která ovlivnila sběr požadavků, architekturu, design, implementaci, atd. Jednou z největších výzev pro zadavatele je v tomto bodě úplně ten první krok, tedy akceptace faktu, že stav je opravdu špatný a žádné rychlé zázračné (a v důsledku ani levné) řešení neexistuje.

Steve McConnell v jedné ze svých slavných knih s názvem Rapid Development dokládá náročnost opravy chyb v různých fázích vývojového cyklu. K tomu také uvádí ilustraci, která je více než názorná:

Problémy bychom neměli ignorovat, jelikož nám dříve či později přerostou přes hlavu a následky budou fatální.

Jaká je tedy správná odpověď na otázku: „Proč bychom se měli SW kvalitou na našem projektu vůbec zabývat?“ Jednoduchá odpověď je, že kvalitní software dlouhodobě šetří čas, peníze, zdroje a navíc je dobře udržovatelný. Je těžké vyčíslit přesné dopady, jelikož neumíme předpovídat budoucnost. Nicméně pokud byste si měli při nákupu nového rodinného vozu vybrat mezi nákupem standardního automobilu, který prošel všemi bezpečnostními testy a splňuje zavedené standardy a vozem, který standardy ani bezpečnostní testy neplní, avšak lze jej pořídit za poloviční cenu a s rychlejším časem dodání, co byste zvolili? Většina z nás by asi neváhala a zvolila možná konzervativnější, ale bezpečnější a v poměru cena/výkon výhodnější první variantu. V případě software kvality se tedy prosím rozhodujme stejně.

Michal Petřík