Zavádění code review 1/5: Náš začátek

O code review se učí ve školách, mluví na konferencích a dělá se ve firmách zvučných jmen. Co přesně to ale je? Jak jsme to zaváděli u nás v Trigamě? A jak to celé dopadlo? Na to by vám měla odpovědět tato série článků.

 

V prvním článku si povíme něco o situaci a problémech, které nás dovedly k zavedení code review. Druhý článek bude trochu rešeršního charakteru, protože se v něm pokusím nastínit, co to code review je a co může přinést. Ve třetím pokračování si povíme něco málo o našem konkrétním provedení, což jistě alespoň částečně uspokojí vaši zvědavost. Ve čtvrtém článku poodstoupíme od samotného procesu code review a podíváme se na proces jeho zavádění. V posledním článku se pak podělíme o naše zhodnocení a ukážeme i nějaká ta data spolu s tipy a postřehy, které nám zavedení code review přineslo.

Jak už je v našem IT odvětví zvykem, nové věci se začínají dít živelněji, než bychom my zúčastnění chtěli. A tak i webový tým (respektive PHP tým) vznikal v Trigamě narychlo, a to v souvislosti s novou velkou zakázkou. Zadání bylo rozsáhlé a času kvapně ubývalo, takže tým hrnul nové funkce závratným tempem a všichni jsme se nemohli dočkat konce.

V té době měl náš tým přibližně 5 vývojářů, z nichž část pracovala na projektu na částečný úvazek, mimo vývojářský tým pak stálo pár dalších lidí, především analytici, testeři, UXák a designér.

Před koncem projektu ale začínalo být všem vývojářům jasné, že postup „dostanu zadání, nakóduji a odevzdám“ (~ zamerguji) nebude nejvhodnější, zejména pak kvůli nespokojenosti prakticky všech vývojářů pracujících na tomto projektu, a to i přes existující společný standard, podle kterého by kód měl být psán (od code style po architekturu).

 

Dali jsme tedy hlavy dohromady a řekli si, co konkrétně nás v daném projektu trápilo či trápí. Vznikl tak následující seznam:

• Nedodržování domluveného code style. Když pak každý soubor, či dokonce různé jeho části vypadají jinak, způsobuje to kromě jisté nejistoty a estetického zhnusení vývojářů častěji přehlédnutí, a to má jen kousek k defektům a z nich plynoucím chybám.
• Ohýbání existujícího kódu. Namísto správné implementace buď novým kódem, nebo refaktoringem stávajícího docházelo ke zneužití stávajícího kódu drobným zapodmínkováním, zkopírováním kódu, přidáním nesouvisejícího parametru či prostě jen znovupoužitím funkce s označením, které v daném kontextu vlastně nedávalo smysl, jen kvůli tomu, že náhodou dělala to, co daný vývojář potřeboval.
• Nekontrolovaná architektonická rozhodnutí, při kterých se vývojář rozhodl, že nějakou požadovanou funkčnost naimplementuje jedním konkrétním způsobem, a neporadil se s týmem o vhodnosti řešení. Později se u řady takových zásahů ukázalo, že extrémně zvyšují komplexitu aplikace a je obtížné se jich zbavit, protože další vývojáři na nich naimplementovali další a další funkcionality.
• Rozbité buildy, takže po odevzdání práce a předání na testera nebyla aplikace ani schopná zobrazit úvodní stránku, natož požadovanou funkcionalitu (za současné obhajoby vývojáře, že jemu to na jeho počítači samozřejmě funguje).
• Velké množství nedodělků a chyb v odevzdané práci, což vede ke znovuotevírání úkolů, pinkání úkolů mezi vývojáři a testery a v konečném důsledku ke všeobecné nespokojenosti.
• Obtížné porozumění cizímu kódu, což vedlo v týmu k rozdělení „já dělám jen toto a tam tomu nerozumím“.
• Používání zastaralých a potenciálně chybových konstrukcí jednotlivých programovacích jazyků.

Objevila se i řada konkrétních odkazů, tyto obecné ale shrnovaly většinu z nich. S code review se velká část týmu už někdy setkala, ať už teoreticky ve škole, nebo v praxi, takže bylo vcelku očekávané, když pojem code review nakonec zazněl jako nápad, jak vyřešit tyto problémy.

Jenže co přesně to code review je? A je to vhodné řešení pro naše problémy? O tom bude navazující článek.