Běžným záznamovým médiem byl stále děrný štítek (ano, přesně tak, kus tvrdého papíru s mnoha malými otvory), na kterém bylo obvykle 80 nebo 90 sloupců pro záznam dat. Aplikace se ukládaly na řadě děrných štítků, jež se musely počítači podávat v přesném pořadí. Pro zajímavost, 80 sloupců znaků v textovém režimu zobrazení je pozůstatek té doby.
Robert C. Martin, spoluautor Agile Manifesto, popsal toto období ve své knize The Clean Coder, kde ti šťastnější používali už datové pásky: „Datové pásky se mohly pohybovat jen jedním směrem, takže když došlo při načítání dat k chybě, musel se proces přerušit a začít načítání znovu. To se stávalo 2 ×–3 × za den. Velmi časté byly i chyby při zápisu a disky nenabízely způsob, jak je snadno odhalit. Proto jsme datové pásky vždy zapisovali ve dvojici a pak jsme je porovnávali.
Pokud byla nějaká páska chybná, ihned jsme vytvořili kopii. Když byly vadné obě, museli jsme začít celou operaci znovu.
Pásky jsme editovali na obrazovce, a to tak, že jsme z pásky načetli ‚stránku‘, upravili obsah a poté ji zapsali a tak dále. Stránka odpovídala typicky 50 řádkám kódu a nemohli jste se podívat dopředu na pásce, které stránky budou následovat, ani zpět na již opravené stránky. A tak jsme používali výpisy, na kterých jsme poznamenali, které všechny změny chceme udělat, a podle těchto poznámek realizovali úpravy. Nebylo možné, aby někdo psal či upravoval kód programu přímo v počítači, to by byla pohroma. Jakmile byly všechny změny hotové, spojili jsme tyto soubory do jedné hlavní pásky, kterou jsme používali ke kompilaci a testování.“
Představte si, jaké následky měla v takovém prostředí kompilační chyba. Museli jste najít správnou pásku, nastavit ji na požadované místo, upravit a uložit na novou, načíst ji… a tak stále dokola, přitom se mohly objevovat nové a nové kompilační chyby. Několik omylů a celé dny práce přišly vniveč. A to pokud jste měli pokročilé vybavení na děrované pásky, v případě v té době obvyklých děrovaných štítků tištěných přes noc se ztráty produktivity počítaly spíše v týdnech než ve dnech.
Není se tedy co divit, že bylo naprosto normální si kód vytisknout a udělat před kompilací pečlivou kontrolu někdy zahrnující i ruční přepisování kódu.
Dnes kontrole kódu obvykle předchází nejen kompilace, ale pokud se používá vývoj zaměřený na testování, provedou se unit testy. Potom záleží na konkrétních podmínkách, zda se vyplatí zařazovat revizi kódu ještě do raných stadií vývoje.
Výzkum
Adam Porter je profesorem na americké Marylandské univerzitě a odborníkem na softwarové inženýrství. Spolupořádal experiment, ve kterém se hodnotily náklady a přínosy formalizovaného review kódu. Počet členů revizního týmu byl proměnlivý, a to od jednoho programátora až po několik, kde měl každý svou danou roli (autor, čtenář, moderátor a reviewer). Adam Porter vyhodnotil svá výzkumná data, přitom ignoroval nálezy, které nebyly opraveny (protože to nemělo vliv na vydaný kód), a „měkké“ problémy údržby jako programovací styl („upravenost“ kódu). Došel k tomu, že týmy s více než dvěma lidmi a několikanásobnou kontrolou nenašly výrazně více chyb než ty prováděné dvěma kontrolujícími a autorem.
Zjistil také, že přidávání dalších lidí vyžaduje plánování schůzí, většinou formalizovaných, tj. v daný čas na určitém místě, což zvyšovalo celou časovou náročnost a zdržovalo vývoj kódu.
Jedním ze závěrů výzkumu bylo, že když se neberou v potaz falešné nálezy a jemné úpravy, jen 13?% nalezených „problémů“ mělo za následek skutečnou úpravu kódu. Což shrnul tak, že spousta úsilí při revizi kódu by se dala nahradit automatizovanými nástroji či standardy.
Adam Porter prováděl svůj výzkum v 90. letech, jenže od té doby se objevila nová radost i starost v podobě agilního softwarového vývoje (Agile Software Development = ASD).
Agilní a extrémní programování
Extrémní programování (XP) přineslo do vývoje mnoho nového, nicméně minimálně dvě věci jsou zvláště důležité pro kontrolu kódu. Za prvé idea programování ve dvojicích přináší výborné možnosti pro trvalou křížovou kontrolu kódu a zároveň Test Driven Development (TDD) zabraňuje compile-time, off-by-one, index a pointer chybám, pro jejichž odhalení byla primárně určena revize kódu.
A za druhé XP zavádí koncept nákladů podle toho, kdy je chyba nalezena. Jinak řečeno, čím později ve vývojovém cyklu je chyba odhalena, tím vyšší je cena na její nápravu (a roste až exponenciálně). Je jednoduché si to představit – chyba odhalená v produkci stojí 100 ×–1 000 × víc než chyba opravená ve fázi specifikací.
V dnešní době se vývojový tým řídící se ideou agilního vývoje posune od požadavků k psaní kódu a pak k testování v rozmezí dnů, někdy i během hodin. Když si představíme dva projekty se stejnou specifikací, jeden realizovaný agilně ve dvoutýdenních iteracích a jeden klasický šestiměsíční („vodopád“), může ten agilní najít chybu v jednom či dvou týdnech, tedy než vůbec dojde k nějaké revizi v případě druhého projektu. A to samozřejmě znamená nižší náklady.
Masivní rozšíření internetu přineslo značné snížení nákladů na opravu chyb. Bývaly doby, kdy napravení softwarové chyby znamenalo rozesílat zákazníkům diskety či CD a s tím související ostudu pro firmu. Dnes je běžnou záležitostí, že se denně instalují automatické softwarové záplaty.
Obojí dohromady znamená, že význam i přínosy revizí kódu se snížily a zároveň poklesla i závažnost rizik, která měla revize kódu pokrývat. Respektive mohou být zajištěny jinými nástroji, jako jsou TDD, párové programování či rapidní testování.
Když se to takto napíše, asi si říkáte, k čemu by tedy dnes byla taková kontrola kódu vlastně potřeba, když je tolik vhodnějších alternativ…
Peer review v praxi
Peter Walen, softwarový technolog a tester ze společnosti Grand Rapids, používá formální revizi kódu více než 15 let a podle jeho názoru má ve vývoji stále své místo. Vždy když někde implementoval program softwarových revizí, znamenalo to pro organizaci přínos. Často v zásadě stačilo spojit programátory a ukázat jim, jak hledat chyby, zejména ty zřejmé.
Zároveň ale upozorňuje, že by organizace neměly na revizi tvrdohlavě trvat. Častý scénář je, že je nalezena významná chyba ve firemním softwaru, jejíž oprava stojí spoustu peněz. Při analýze se zjistí, že by konzistentní revize kódu takové chybě zabránilo, a tak jsou zavedeny patřičné procesy. Postupně se však nutnost systematického kontrolování kódu vytrácí i díky pozitivním efektům samotné revize. Jedním z nich je, že programátoři si dávají větší pozor na svůj kód, už jen aby si neudělali ostudu. Dalším je přesun důrazu od hotového kódu na specifikace a technický design. A tak když dojde k celkovému vylepšení vývojářské kultury v organizaci, nemusí formální kontrola kódu přetrvávat.
A co dál?
Formalizovaná revize kódu vznikla v jiné době softwarového vývoje, kdy kompilace trvala hodiny, aplikace neměly grafické rozhraní a fungovaly v dávkovém zpracování („batch mode“). Pokud je kontrola formálním krokem, kterého se účastní lidé z jiné místnosti, vyžaduje to často schůze a zvyšuje čas spotřebovaný na projektu. Výzkumy říkají, že tyto dodatečné náklady mohou být převáženy přínosy, na druhou stranu projekt může stejně tak těžit z neformální kontroly kódu prováděné mezi kolegy ihned poté, co je dokončeno programování jedné části. Alternativou je i programování ve dvojicích.
Pokud plánujete zavést formalizované revize kódu, jako první si položte otázku, jaký problém by to mělo vyřešit a zda váš tým skutečně takovou potíž má. Pokud je například problém v tom, že se nestíhá vývoj, některé části chybějí či je navržené uživatelské rozhraní příliš složité, kontrola kódu nepomůže.
Kromě „obyčejného“ nalézání chyb může být motivace pro zavedení revizí i jiná, například sdílení znalostí kódu a programovacích postupů, pomoc analytikům a testerům vyznat se v tom, co bylo vytvořeno, a pokud se podílejí i neprogramátoři, snaha, aby byl kód snadno čitelný i pro ně, tedy aby nebyl příliš složitý (to zahrnuje i programátorskou kulturu jako používání komentářů).
PŘEDPLATNÉ
ČLÁNKY DO MAILU