Zavádění code review 4/5: Proces zavádění

Jak se dostat od pouhého nápadu k funkčnímu code review? Jak přesně to probíhalo v Trigamě? O tom je dnešní předposlední článek ze série o zavádění code review.

 

Spouštěč

Jak už jsem naznačil výše, spouštěčem u nás byl nápad vývojového týmu, že problémy pojmenované týmem (viz první díl) by šly adresovat zavedením procesu code review.

V jiných případech to může vzejít i od projektového manažera či vyšších manažerů nebo konzultantů, což někdy může být vcelku nevděčné (viz níže vložený tweet od Ocramia). V případě, že spouštěčem je vývojový tým, máte skoro vyhráno, největší část práce v přesvědčování o výhodách máte za sebou, žádný boj s direktivními nařízenými procesy vás nečeká.

 

Předpoklady

Pro zavedení code review vidím osobně jako nezbytné následující předpoklady:

1. Mít garanta změny – někoho, kdo si to vezme za své a bude mít dostatek kompetencí (případně diplomatických schopností) k prosazení změn.
2. Mít podporu vývojového týmu – protože nařizovat vývojářům, jak mají pracovat, nebyl nikdy ten nejefektivnější způsob.
3. Mít podporu manažerů – z jejich pohledu code review zvýší čas na úkol, celý proces by však měl snížit počet chyb v produktu, a tedy v budoucnosti také snížit vytížení týmu opravou chyb. V případě menších projektů je toto obtížněji kvantifikovatelné a v případě krátkodobých zakázek vlastně i potenciálně nechtěné (obzvláště chcete-li dodat co nejdříve a více už neřešit). Přesto může být žádoucí, aby měl tým kontrolu nad kvalitou kódu, který chce vyvíjet, protože právě to jej udržuje funkční.
4. Mít tým schopný dosahovat konsenzu v různých otázkách ohledně vývoje. Bez toho nebude tým schopen překonat diskuze a konflikty, které při code review zcela jistě nastanou. Důležité je uvědomit si, že nekonsenzuální řešení těchto situací (direktivní, kompromisní nebo většinové) může vést (a typicky vede) k rozbíjení týmu.

Bez splnění těchto základních předpokladů se zavedení code review buď nezdaří, nebo nebude plnit svůj účel. Všechny problémy se dají překonat, vyžadují ale kus diplomacie, kus personalistiky, kus soft skills, a hlavně dostatek času.

 

Vhodné předpoklady

Kromě nezbytných předpokladů zmíněných v předchozím odstavci je i řada těch vhodných, z nichž zde zmiňuji ty opravdu důležité.

• Vlastnictví kódu je sdílené týmem (resp. firmou) a celý tým má za cíl udržovat vysokou kvalitu tohoto kódu. Proč kontrolovat kvalitu kódu v jiné části aplikace, která není moje? Bez tohoto vidění týmu se code review dřív nebo později zvrhne na „jednou to potvrdím já tobě, podruhé zas ty mně“.
• S předchozím souvisí i to, že nějaký tým existuje a je jako skupina funkční (z pohledu skupinové dynamiky), má společnou identitu, kulturu a cíl. Pokud cíl firmy je vyvíjet kvalitní produkty, ale cílem vývojářů je lehce vydělat peníze, bude to prostě drhnout.
• Jednotliví vývojáři by měli chápat (a mít zkušenost), že „A code review is not a place for blaming or shaming...“. Chápat by to měli i jednotliví manažeři, kteří by se měli zdržet nápadů, že budou posuzovat kvalitu vývojářů podle množství nedostatků nalezených při code review. Jinými slovy, že jednotliví členové týmu se cítí být v (emocionálním) bezpečí, když jiní lidé nacházejí mé chyby.
• Pokud se v produktu přeci jen objeví chyba, nejde až tak o chybu jednotlivce, ale o chybu týmu (+ manažerů), který společně jako celek nedokázal skrze nástroje QA při vývoji zajistit, že se to nestane.
• Pro kvalitní code review potřebujete vědomí dostatku času, uspěchané deadliny a lidé za zády kvalitě rozhodně nepřidají.
• Přesvědčení, že nejde o ztracený čas. Řada vývojářů totiž smýšlí tak, že když nepíší kód a nekomitují X-krát za den, nejsou produktivní.

Najdete určitě spoustu dalších pozorování, jejichž dobrým souhrnným ukazatelem je, jestli sami vývojáři chtějí, aby jejich kód byl reviewován.

 

Samotné zavedení

V Trigamě bylo zavedení code review svěřeno mně. Sestavil jsem tedy níže uvedený seznam bodů na cestě ke code review. Následně jsem na základě rešerše sestavil proces samotného code review a zapsal jej jako Markdown dokument do merge requestu do našich vývojových standardů. Poté jsem jej probral s pár zainteresovanými kolegy a následně představil všem kolegům v prezentaci a následné diskuzi.

1. Prvním bodem bylo vyjasnění si očekávání a ověření (diskuzí), zda je jejich splnění pomocí code review reálné.
2. Dále bylo potřeba ujasnit si všechny důležité otázky (kdy, komu a co) o samotném procesu code review, viz předchozí díl.
3. Určení evaluačního období a kritérií, podle kterých zhodnotíme, zda naše očekávání byla naplněna, respektive jestli pro nás má code review nějaký přínos.
4. Prezentování tohoto návrhu všem relevantním osobám a doladění na základě jejich postřehů.
5. Určení osoby, která bude řešit případné dotazy a bude schopná po určitou zaváděcí dobu asistovat u code review z procesního, kódového i emocionálního hlediska.
6. Zvolení časového bodu, od kterého začneme, čím dříve, tím lépe.
7. Monitorování, zda code reviews probíhají, namátková kontrola toho, jak probíhají, a po zvoleném čase veřejné vyhodnocení, jak si stojíme, a rozhodnutí, jestli budeme v code review pokračovat.

 

Den D

V den, kdy jsme code review začali používat, se nic moc nezměnilo, jen namísto toho, aby si vývojář řešící úkol po dokončení práce sám rovnou zamergoval, poslal své code review do Slacku týmu a byl odměněn pěknou sadou komentářů v GitLabu a pochvalou, že je to skoro OK...

Je pravda, že ne vždy to od té doby šlo takto hladce, ale pokaždé jsme zvládli problémy překonat. Hlavní je uvědomovat si, že vše nemusí být hned perfektní, ale vždy by to měl být krok vpřed, a hlavně něco, co můžete nadále rozvíjet, měnit a celkově vzato zlepšovat.

 

V posledním článku série se příště dozvíte, jak jsme zavedení code review zhodnotili, uvidíte i nějaká čísla (byť jich nebude mnoho) a seznámíte se s řadou postřehů a tipů.