Code Review je důležité a má vliv na morálku týmu

Code Review (revize kódu) je důležitá technika zajišťující spolupráci mezi vývojáři, která napomáhá k zvyšování kvality psaného zdrojového kódu a neméně důležitým dopadem je i sdílení znalostí napříč týmem či celou společností. Této techniky se však často bojí lidé, kteří se s tímto přístupem k vývoji software nesetkali.

Pro jednoho to znamená, že se jedná o nezbytnou kontrolu, zda je změna kódu přijatelná a má se integrovat do celkového kódu. Pro jiného je celkem děsivé, že někdo druhý bude procházet jeho kód a aktivně hledat chyby, které v něm jsou.

Jak na revizi kódu

Píšeme jasné komentáře s respektem k hodnocenému

V rámci revize se neodkazujeme na schopnosti daného vývojáře či jeho technologické znalosti. Tento typ komentářů ztrapňuje člověka, kterému jsou určeny. Zvlášť pokud jsou komentáře veřejné. Pokud je nutné mentorování vývojáře, aby se zvýšily jeho schopnosti, tak využijeme jiné kanály, které nevytvářejí tyto negativní pocity.

Vyhněme se čemukoli, co autora kódu přiměje se chovat defenzivně, nebo bude mít pocit, že musí obhájit svou práci, kterou udělal tak, jak nejlépe uměl.

Komentáře píšeme tak, že jsou jasné a ihned srozumitelné, aby nedocházelo ke zbytečným nedorozuměním. Než komentáře odešleme hodnocenému, raději si ho ještě jednou po sobě přečteme a zaměříme se na to, zda dávají smysl a specifikace je jednoznačná. Zvyšujeme tím pravděpodobnost bezproblénového přijetí ze strany hodnoceného.

Revize kódu nemusí být zaměřena pouze na kritiku, ale samozřejmě můžeme v ní i cokoliv ocenit, abychom těmito příjemnými slovy a pochvalou povzbudili práci hodnoceného. Mějme na paměti, že většina populace má ráda komplimenty a pozitivní hodnocení.

Při revizi udržujeme rovnováhu mezi důsledností a efektivitou

Při revizi kódu můžeme vysledovat časté dohady ohledně toho, co by hodnotitel měl vyžadovat v rámci jeho práce. Určité komentáře jsou vítany, především ty, které se zaměřují na kód nebo např. volání nevhodné knihovny. Nicméně, co se týká stylu psaní zdrojového kódu nebo jeho čitelnosti, se v takovém případě může hledat rovnováha velmi obtížně.

Někteří vývojáři dávají přednost revizi, kdy jakýkoliv komentář směrem ke kódu je považován za férový a zajišťuje dodržení vysoké kvality kódu. Tento přístup má jistou logiku, nicméně přináší zvýšení nákladů pro vývoj. Kontrola kódu je časově náročná, a to jak pro revizory, tak pro autory kódu. Každé další kolo komentářů a odpovědí ubírá energii a čas pro psaní dalšího kódu. Je třeba si také uvědomit, že kód, který je kontrolován, může také blokovat další změnové požadavky, které na této revizi závisí. Takto můžeme celkem snadno vytvářet úzká hrdla, která jsou nežádoucí.

Je důležité, aby integrace kódu skrze jeho revizi byla zajišťována co nejdříve, protože změny, které musíme zajistit mohou být důležité. Blokování v rámci kontroly může mít vážné negativní dopady na to, jak rychle se věci hýbou.

Revize kódu ovlivňuje vztahy mezi lidmi

Přestože je efektivita práce důležitá, dopad na týmové vztahy je ještě důležitějším důvodem pro omezení rozsahu komentářů v revizích kódu. Přijímání kritické zpětné vazby může být obtížné, přestože je zpětná vazba očividně užitečná a dobře míněná.

Představme si situaci, kdy se revizor zeptá, zda hodnocený přemýšlel, že lze algoritmus napsat jiným a mnohem lepším způsobem. Hodnocený, který vynaložil velké úsilí pro napsání algoritmu při této otázce automaticky naskočí do obranného mechanizmu. Je tedy na hodnoceném, aby dokázal vynaložit takové usílí, které ho přiměje se nad návrhem zamyslet a případně uznat, že hodnotitel má pravdu a změnu má udělat.

Lidé jsou plní emocí a jejich emoce jsou i součástí věcí, které vytvořili.

Je přirozenou lidskou vlastností být hrdý na svou práci a automaticky ji začít bránit. To neznamená, že by vývojáři neměli vnímat zpětnou vazbu ostatních. Lidé dokážou překonat svou hrdost, pokud cítí, že je to opravdu z dobrého důvodu. Pokud se cítí být tlačeni do nesmyslných změn, můžeme tím snadno poškodit vzájemné vztahy.

Cílem revize je to, že lidé vnímají, že pro hodnotitele je požadovaná změna důležitá a přistupují svou reakcí k jeho požadavku přátelsky.

Vyhněme se pedantskému přístupu k hledání nedostatků

Pokud uděláme experiment, kdy se přestaneme zaměřovat na detailní revizi, zda kód je ve všech standardech ideální, zjistíme, že to až tak velký dopad na kvalitu kódu nemá. Dokonce nebude ani raketově stoupat počet hlášených chyb. Kód tím nebude moc trpět a dokonce budeme pozorovat prohlubování spolupráce mezi lidmi. Zjednodušeně na kvalitu kódu nemá vliv lpění na optimalizaci názvu proměnných či dodržování stylistických preferencí.

Chyby, které jsou v kódu, nejsou způsobeny nedodržením malých stylistických standardů a neopraví je ani následné malé refaktoringy.

Svou energii zaměřujme na vyšší účel, jako je architekura řešení a skutečné chyby v kódu. Netravme čas optimalizací názvu proměnných pokud si nevšimneme vzoru, který by měl být adresovaný. Obávejme se mnohem méně toho, že by jednotlivé řádky kódu způsobily problémy, než to, že naše loď pluje nesprávným směrem a náprava bude velmi těžká.

Pro týmy, které i tak chtějí dále kontrolovat standardy stylu psaní, doporučuji, aby to udělaly jiným způsobem. Vyhraďme si čas na diskuzi, jak standardy psaní kódu mají vypadat a potom použijme automatickou kontrolu např. přes statickou analýzu kódu.

Zkusme si závést do revize kódu dva stupně komentářů, které mohou pomoci hledat rovnováhu vynaloženého úsílí hodnotitele a hodnoceného.

  • povinná změna – bez této změny revize nabude označena za přijatou, protože má zásadní dopad na kvalitu kódu
  • nepovinná změna (doporučení) – je čiště na hodnoceném, zda doporučenou změnu zohlední či nikoliv

Budujme mezilidské vztahy mimo revizi kódu

Můžeme to zkusit, jak snadno někomu ublížíme skrze neosobní nástroje. V online prostředí mohou lidé znít různě a mohou působit prudším komunikačním stylem. Vidíme to často, že lidé, kteří nepracují fyzicky spolu, tak se jim buduje díky vzdálenosti hůře vztah a tím mohou vznikat i zbytečné konflikty.

Týmu musíme vytvářet takové příležitosti, aby se mohli jednotliví členové poznávat mezi sebou, aby díky tomuto poznání mohli lépe chápat záměry jednotlivých vývojářů. Každý má možnost se dozvědět jak daný člověk pracuje a jakým způsobem komunikuje, a proto je tak důležité budování vztahů mimo revize kódu.

Je důležité stavět revizi kódu na důvěře a pocitu bezpečí.

Tyto aktivity by měly zahrnovat socializaci, setkávání se na denních schůzkách nebo spolupráce na psaní kódu jiným způsobem. Jedním z oblíbených způsobů jak psát společně kód je technikou Pair Programming. Párové programování samozřejmě může být alternativou k psaní komentářů v rámci revize kódu.

Pokud se stane, že komentářové vlákno je již příliš dlouhé je vhodné ho přenést do jiného kanálu (online komunikátor, telefon atd.), což ušetří čas a souběžně omezí vznik nepřátelství.

Shrnutí

Skutečným cílem revize kódu je budování znalostí a vzájemných vztahů. Proto je tak důležité, abychom revizi kódu dělali dobře a všichni mohli těžit z benefitu učícího se prostředí.

Podstatou revize kódu je porozumění – dozvědět se více o svém týmu; software, který vyvíjíme; o způsobu komunikace, který mezi sebou používáme; o potřebách našich zákazníků. Výsledkem je méně chyb, mnohem kvalitnější kód a vyšší stabilita. To vše je výsledkem dobře nastaveného procesu a snahy o pochopení, co náš kód skutečně dělá.

Sdílejte s přáteli

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *