Revize kódu a jejich smysl v Agilních přístupech

Tradiční oddělení kvality a také některé firemní procesy a dobré praktiky vyžadují revizi kódu. Jaký je smysl těchto revizí, jak je možné je provádět a mají vůbec smysl při agilním způsobu vývoje (jsou implicitní součástí)? To jsou otázky na které se snažím odpovědět v tomto příspěvku.

Revize kódu podle tradičního přístupu oddělení kvality slouží ke kontrole a retrospekci napsaného zdrojového kódu. Smyslem je nejen kontrolovat kvalitu a strukturu vlastního zdrojového kódu, čili odhalení možných nekonzistencí a chyb (přece jen každý píšeme a dokumentujeme kód jinak, každý jsme totiž typologicky odlišný), ale také kontrola dodržování dohodnutých konvencí zápisu kódu a dokumentace, komentářů kódu (což je asi jediná dokumentace, kterou kdy vývojáři čtou ;)). Znalosti a dovednosti člověka provádějícího revize jsou zde kritickým faktorem úspěchu. Tato tvrzení platí převážně pro tradiční způsob vývoje software, který zdůrazňuje opakované přesně definované procesy jako nejdůležitější faktor úspěchu (a opomíjející lidský faktor, přece jen každá jsme jiný, máme jiné dovednosti, zkušenosti, vnitřní motivaci).

Platí stejný způsob revizí i pro agilní týmy? Provádíte revize kódu ve vašem agilním týmu? Jsou formální revize kódu opravdu nutné, když praktiky jako defenzivní programování, párová práce, TDD, neustálá integrace či retrospektivy snižují riziko výskytu chyby na minimum? Pojďme si nejdříve shrnout smysl, perspektivy a úroveň detailu revizí kódu:

• Kontrola následování mechanismů architektury – smyslem je ověřit, zda jsou následovány dohodnuté mechanismy architektury, implementovány vrstvy, návrhové vzory a definována relevantní rozhraní dohodnutá s jinými týmy/systémy/dodavateli. Byznys logika, volání akcí, kontroly vstupů, všechny tyto kroky jsou ošetřeny na relevantní vrstvě a podle dohodnutých návrhových vzorů. Například kontrola na správnost a prázdnost vstupů by měla probíhat již na vrstvě UI, ne až při zpracování byznys logikou. Tyto revize jsou prováděny většinou architektem systému. Jejich úroveň detailu se pohybuje v pojmech vrstev, balíčků či tříd. Neřešíme detailní úroveň kódu, i když můžeme zahrnout také některou z následujících tří perspektiv.
• Detailní kontrola zdrojového kódu je zaměřena na samotnou implementaci algoritmu, nastavení proměnných, kontrolu vstupů a čitelnost (tím pádem i údržbu) zdrojového kódu. Součástí této úrovně kontroly jsou také následující dvě perspektivy.
• Konvence zápisu kódu jsou dohody o formě zápisu kódu uvnitř metod a tříd; pojmenování balíčků, tříd a jejich instancí, metod, vizuální oddělení logických celků metod, pojmenování proměnných a konstant. Konvence pomáhají srozumitelnému čtení obsahu a porozumění účelu tohoto obsahu. Srovnejte váš první napsaný komerční kód (ne školní projekty ;)) a zdrojový kód některého z Open Source projektů Eclipse (např. Eclipse Web Tools Platform a konvence kódu podle Eclipse). Vidíte ten rozdíl? Dokážete si představit údržbu vašeho kódu po 3 letech a údržbu kódu Eclipse WTP?
• Dokumentace zdrojového kódu (komentáře) je velmi často jediná dokumentace, kterou vývojáři čtou a píší. Proto je dobré jí věnovat pozornost. Tato dokumentace je také jednou z nejdůležitějších v agilních projektech. Smyslem je dokumentovat návrhová rozhodnutí a účel jednotlivých algoritmů či volání.

Pokud se zeptáme zastánců revizí, proč je provádí, proč na nich trvají? Pak typická odpověď je ve smyslu zvýšení kvality, menšího množství chyb… Mají tedy revize přesto smysl, když tento cíl můžeme zaručit vlastním procesem vývoje (Agilním a Lean). Spíše než odhalovat chyby (což je jedním ze smyslů revizí), je chyby nedělat. Jakékoliv odhalování a opravování chyb je totiž plýtvání (waste). Trávíme čas revizí, přípravou na ni, opravou, což stojí čas někoho z týmu a tím pádem i peníze zákazníka. Proto lepší než zaměření se na revize je zaměření se na proces vývoje a pomocí retrospektivy a zapojení všech členů týmu ho neustále upravovat (zlepšovat) směrem k ideálnímu procesu vzhledem k omezením plynoucím z domény, technologie, organizace či zkušeností a dovedností členů týmu.

Uvážíme-li agilní týmy, které jsou v implementaci agilního způsobu práce zralé (nejen co je týká aplikovaných technik a praktik, ale také způsobu myšlení), zjistíme, že v Agilních přístupech jsou revize (všechny výše zmíněné pohledy) vestavěnou a nedílnou součástí modelu vývoje. Co tím přesně myslím? Základem agilních přístupů je spolupráce všech členů týmu a neustálá zpětná vazba, oba tyto principy jsou podpořeny řadou praktik či nástrojů, jmenujme například následující:

• Testy řízený vývoj – TDD – mající za smysl promyslet nejlepší variantu návrhu řešení díky tomu, že nejdříve napíšeme test tohoto řešení.
• Párová práce – pravidelná párová práce má za smysl eliminovat možnost přehlédnutí chyby, nenásledování dohodnutých konvencí pro psaní kódu a dokumentace a také pravidel architektury (jedná se vlastně o instanční formu všech 4 forem revizí).
• Neustálá integrace (Continuous Integration – CI) mající za cíl často (i několikrát denně pokud to umožňuje technologie) sestavovat současný build a spouštět na něm testy. Tato zpětná vazba umožní odhalit případné problémy a chyby velmi brzy, nutnost přepracování či oprav je pak minimalizována na úroveň denního objemu práce.
• Demonstrace zákazníkovi.
• Testování součástí každé iterace/sprintu.
• Retrospektiva na úrovni týmu týkající se procesu vývoje i architektury, tj. struktury kódu, pravidel pro zápis kódu, dokumentaci.

V agilních projektech je tedy revize vestavěnou součástí praktik. Revize na úrovni architektury probíhá párovou prací s architektem, TDD a CI. Detailní jsou pak řešeny denní párovou prací mezi programátory, opět TDD a neustálou integrací s pomocí automatizovaných nástrojů. Revize jsou také často podpořeny nástroji díky moderním IDE jako je Eclipse, NetBeans či MS Visual Studio. Kontrola konvencí pro zápis kódu, statická kontrola, kontrola připojení DB, přestupky proti architektuře, kruhové závislosti a další mohou být také součást denních buildů, např. pro Javu jde o Findbugs, Checkstyle, Lint4J, JDepend, Macker, *Unit, PMD, CPD, JavaNCSS.

Přesto všechno mají formální revize smysl minimálně ve dvou případech:

1. Životně kritické systémy (mission ctitical systems),
2. Agilní týmy, které ještě nemají zavedené komplexnější vestavěné mechanismy jako je TDD či CI.

Pro tyto týmy jsou formální revize důležité a může jim pomoci následující seznam otázek (checklist):

1. Je kód čitelný a pochopitelný (tj. snadno udržovatelný)? Následuje dohodnuté konvence? Tato otázka je mírně subjektivní, ale s pomocí definovaných konvencí a nástrojů, které jsou součástí IDE je možné ji poměrně rychle automatizovat a zobjektivnit.
2. Odpovídá implementace dohodnutým pokynům a pravidlům architektury (žádné kličky a přeskoky vrstev, podezřelý či neschválený Open Source kód)? Opět je možné postupně automatizovat nástroji.
3. Existují automatizované test casy (nebo alespoň semi-automatizované), které testují daný kód? Pokud ano, jaké jsou jejich výsledky? Testy nemyslíme pouze funkční, ale také nefunkční testy jako je testování dostupnosti, výkonnosti apod.
4. Odpovídá daný kód funkčním a nefunkčním požadavkům (rozšíření předchozí otázky)?
5. Následuje kód běžné/dohodnuté praktiky návrhu jako je objektově orientovaný návrh podle rozhraní, návrhové vzory (např. http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm)?
6. Existují nějaké otevřené, nevyřešené chyby detekované IDE či jinými nástroji, které by měly být opraveny?
7. Existuje cesta, jak udělat kód jednodušší, čitelnější (například refaktoring, odstraněním duplikovaného kódu do knihovny, použitím standardních řešení)?

I když tento seznam vypadá docela dlouze, měla by revize trvat opravdu krátkou dobu, maximálně v řádu desítek minut. Navíc v různém kontextu mohou být dané body poněkud irelevantní (například starší systémy s logikou na úrovni vnořených databázových procedur, některé mainframe systémy, business inteligence řešení atd.). Snahou týmu by však mělo být co nejvíce těchto bodů automatizovat a vestavět do denních praktik, jak bylo vysvětleno výše.

Jaká je vaše zkušenost? Provádíte revize kódu? Vidíte v nich smysl? Máte je automatizované a vestavěné ve vašem procesu?