Ako na efektívne code reviews: tipy a triky

Zle nastavené procesy pri vývoji softvéru môžu priniesť firme namiesto očakávaných benefitov nezanedbateľné škody. Ak si čítal náš predchádzajúci článok Code reviews: sú užitočné alebo strata času?, tak už vieš, že k nim patrí aj Code review, teda kontrola kvality kódu podľa dohodnutých pravidiel.

Code review nastáva pred uložením zdrojového kódu do repozitára a vykoná ju vývojár, ktorý sa nezúčastnil naprogramovania daného kódu. Môže zahŕňať široké spektrum aktivít od jednoduchého čítania kódu spoločne s autorom za jedným počítačom až po tímové mítingy, kde sa rozoberie každý riadok kódu.

Obaja účastníci, ktorí sa podieľajú na Code review, by mali vedieť spolupracovať. Procesy a kritériá stanovené na kontrolu kódu by mali byť známe vopred, inak hrozí, že procesy sa budú zdĺhavo naťahovať a medzi oboma stranami vznikne napätie.

V tomto článku sa zameriame zefektívnenie procesov kontroly kódu, ako aj na tipy a triky pre obe strany, autora aj recenzenta.

Všeobecné osvedčené postupy

• Ak si softvérová spoločnosť zadefinuje Code review ako súčasť Defintion of Done (to znamená podmienky, ktoré musia byť splnené, aby bola daná úloha uznaná ako splnená), je nutné, aby vyhradila pri plánovaní potrebný čas. Nie je nič horšie, ako keď sa kontrola nevykoná dôkladne pod časovým tlakom blížiaceho sa konca termínu na vývoj aktuálnej verzie.
• Efektívnosť Code review spočíva v minimalizovaní interakcií medzi obomi stranami, rovnako ako v skrátení potrebného času na kontrolu. Ak autor dostane niečo prerobiť, ideálne je, keď má potom k dispozícii všetky potrebné informácie, čo je potrebné zmeniť, aby nasledujúca kontrola prebehla úspešne.
• Komunikácia medzi recenzentom a autorom by mala byť plná pochopenia a empatie. Cieľom je spolupráca a spoločné identifikovanie slabších miest v kóde a nie hádky koho riešenie je lepšie, alebo asociácia typu: „Povedal, že môj kód je zlý, takže vlastne hovorí, že ja som zlý“.
• Na Code review sa nekontroluje, či bude daný kód fungovať. Kontroluje sa iba otestovaný kód.
• Kontrola kódu by nemala trvať dlhšie ako hodinu. Ak sa venujeme akejkoľvek činnosti, ktorá od nás vyžaduje maximálne sústredenie dlhšie, náš výkon začne klesať.

Autor kódu (author) – best practises

• Požiadaním niekoho, aby sa pozrel na tvoj kód nikoho neobťažuješ.
• Je vhodné si pred kontrolou kódu svoje riešenie prebehnúť a upraviť miesta, ktoré by mohol recenzent na kontrole vytknúť. Po absolvovaní viacerých kvalitatívnych kontrol kódu získaš cit a budeš vedieť, kam zamerať svoju pozornosť.
• Spätnú väzbu nikdy neber osobne, hodnotí sa kód, nie tvoja osobnosť.
• Autor by sa mal vyhnúť rozsiahlym pull requestom. Je vhodné posielať na kontrolu menšie samostatne funkčné celky. To zrýchli nielen proces kontroly, ale zároveň sa kód následne aj ľahšie opraví.
• Ak sa recenzentovi niektoré časti kódu nepozdávajú, namiesto tvrdého argumentovania (v horšom prípade hádania sa) sa pokús od neho získať viac informácií. Napr. otázkou „Ako by si naprogramoval túto časť ty?“ sa môžeš dozvedieť viac, ako danú časť kódu vylepšiť.
• Ako autor kódu by si si mal robiť podrobné poznámky, nečakaj že ich dostaneš od recenzenta.

Recenzent (reviewer) – best practises

• Nemal by odkladať Code review, pretože niekto naňho čaká s očakávaním, že si pozrie jeho kód. Preto je vhodné Code review priorizovať, to urýchli proces a odstráni frustráciu z čakania.
• Na začiatku kontroly kódu je vhodné sa uistiť, že autor chápe, že to nie je osobný útok, ak dostane niečo prerobiť, pretože nato existujú pádne dôvody. Napr. prepísanie dvoch cyklov do jedného kvôli optimalizácii.
• Recenzent poskytuje spätnú väzbu a mal by ju formulovať voliteľným štýlom, teda že by bolo dobré, keby autor ešte upravil tamto či ono. Nie štýlom, že toto ešte musí autor opraviť.
• Recenzent by sa mal viac zameriavať na štruktúru kódu, ako na jednotlivé riadky. Riadky kódu aj keď napísané svojským štýlom pokiaľ fungujú tak sú relatívne v poriadku, horšie je to s ťažkopádnym kódom náchylným na chyby. Preto odporúčame zamerať energiu na dôležité časti kódu.
• Je lepšie sa na kontrolovaný kód najskôr pozrieť osamote a vytvoriť si naňho názor a pripraviť si prípadne otázky na autora kódu. Ak kód prvý krát vidíme na spoločnom stretnutí s autorom môžeme mať tendenciu nechať sa ovplyvniť jeho obhajobou.
• Nikdy neobviňuje autora, že urobil niečo zlé. Môže sa opýtať, či existuje na to nejaký dôvod, prečo sa rozhodol pre daný variant. Ak vidíme, niečo čo sa nám nepozdáva, je vhodné to sformulovať: „Keby som to robil ja, tak …“ a podložiť to reálnym príkladom.
• Recenzent by sa nemal vystatovať, že on by ten kód napísal na menej riadkov kódu a rýchlejšie.
• Musí byť konkrétny. Spätná väzba typu „Dalo by sa to urobiť aj lepšie“ nie je konštruktívna a autor nebude vedieť ako ju pretaviť do lepšieho kódu. Vhodné je, aby si autor odniesol poznámky, ako konkrétne čo zlepšiť.
• Ak je potrebné zmeniť väčšiu časť kódu, je vhodné vyhradiť si dosť času a prejsť si to s autorom osobne a zodpovedať mu všetky položené otázky.
• Taktiež by mal pochváliť všetko, čo nie je negatívne, resp. čo je naprogramované, tak ako očakávame.

Ak si Java programátor a hľadáš prácu, pozri si naše benefity pre zamestnancov a reaguj na najnovšie ponuky práce.

O autorovi

Jozef Wagner

Java Developer Senior

Viac ako 10 rokov programujem v Jave, momentálne pracujem v msg life Slovakia ako Java programátor senior a pomáham zákazníkom implementovať ich požiadavky do poistného softvéru Life Factory. Vo voľnom čase si rád oddýchnem v lese, prípadne si zahrám nejakú dobrú počítačovú hru.