Show Menu
Cheatography

Peer Review (cz) Cheat Sheet by

Jak na peer review - sbírka doporučení a best-practice.

Co je peer-r­eview?

Pohled na výsledek činnosti kolego­u/k­olegyní ze stejného nebo příbuzného oboru.

Primárními cíli jsou:
a) validace kvality výsledku
b) sdílení zkušeností a informací

Speci­álním případem peer-r­eview je code-r­eview, kdy dochází ke kontrole zdrojového kódu software.

revi­ewer - Kvalif­ikovaná osoba provád­ějící review.
revi­ewee - Osoba předkl­ádající výsledek své práce k review.

Pokud není dostupná kvalif­iko­vanější osoba pro provedení review, je vhodné jej provést stejně v rámci předání informací a mechanismu self-r­eview (aneb nutností informace vysvětlit je autor sám validu­je).

Kdy se provádí peer-r­eview?

Odevzd­áváme hotový výsledek
Rev­iewee připraví veškeré podklady pro provedení review, předá je vhodnou formou review­erovi a je k dispozici pro případné dotazy. Reviewer provede review a své poznatky předá/­pro­dis­kutuje s revi­ewee, který následně zapracuje připom­ínk­y.
Průběžně během práce
Reviewer průběžně kolaboruje s reviewee a validuje tak jednotlivé mezivý­stupy. Je vhodná před odevzdáním rychlá valida­ce. Standardně se používá pří technice "­pár­ová­ní" (pair-­pro­gra­mmi­ng).

Doporučení pro peer-r­eview

Respekt, slušnost a otevře­nost je nutný předpoklad pro provádění review.
Review ideálně prov­ádějte na menším rozsahu a častěji.
Review neod­klá­dej­te, ale také nedě­lejte předča­sně.
Review musí být efekti­vní, omezte čas na nutné minimum.
Zaměřte se na důleži­té, nezano­řujte se do přílišných argume­ntací a detailů.
Neko­ntr­olujte, co zkontr­oluje stroj.
Doho­dněte si pravidla pro provádění review ve svém týmu.
Nevy­mýš­lejte kolo a využijte, co již existuje.

Doporučené otázky v rámci review

Jsem spokojený s výsledkem, který odevzdávám k review?
Kdybych byl na jeho místě, co bych udělal jinak? Proč?
Co se může stát a s jakou pravdě­pod­obn­ostí, pokud konkrétní nález nebudeme řešit? (řízení rizika)
 

Code-r­eview checklist

Řešení odpovídá zadání
Vyvinutý software odpovídá dohodám, splňuje akceptační kritéria a standa­rdy­/pr­aktiky platné v daném kotnextu.
Standardně znamená splnění defino­vaných akcept­ačních kritérií, což je vhodná nechat si při předání k review ukázat.
Změna je současně verzována a navázána dle konvencí na zadání (např. identi­fikace požadavku v commit message ve VCS systému).
Sroz­umi­telnost a udržov­ate­lnost
Kód je pochop­itelný bez zbytečné komplexity (simple design), vhodně zdokum­ent­ovaný, adekvátně strukt­urovaný pro splnění základních praktik správného návrhu (KISS, DRY, SOLID, YAGNI).
Kód nevyžaduje dodatečný refakt­oring, odpovídá týmovému styleg­uide.
Řešení je bez zjevných chyb
Kód je zkompi­lov­atelný a provoz­ova­telný (stand­ardně projde CI).
Kód neobsahuje zjevné chyby a známé proble­matické části. Standardně používané nástroje nenalezly v kódu relevantní chyby ani upozornění (kompi­látor, IDE, lintery a statické analyz­átory kódu, aj.).
Kód neosahuje známé antipa­tterny, vulner­abi­lity, riziková místa.
Defe­nsivní přístup
Kontrakty a assump­tions v kódu (např. u API) jsou kontro­lovány vč. vstupu­/vý­stupu (asser­tions, kontrolní podmínky).
Výjimky a chyby jsou korektně ošetřeny na vhodné úrovni abstrakce a zdokum­ent­ovány jako součást kontraktu API.
Kód je maximálně thread­-safe, korektně pracuje se zdroji, nepoužívá zastaralé objekt­y/o­per­ace.
Otes­tov­anost
Kód je pokrytý deskri­pti­vními automa­tickými testy na vhodné úrovni (unit, contract, integr­ation, e2e), testy slouží jako dokume­ntace případů užití.
Doporučená sémantika testů je given/­whe­n/then. Testy jsou atomické - 1 test pro 1 scénář.
Tele­metrie - logování a monito­ring
Kód je pokrytý logováním dle principů a standardů logování pro případnou detekci problému (využíváme standardní logovací mechanismy a stejné konvence pro veškerý kód alespoň na úrovni aplikace). Logování neobsahuje nezabe­­zp­ečené citlivé údaje.
Aplikace je pokryta monito­­ringem dle principů a standardů monito­ringu pro zajištění kontroly za provozu. Aplikace poskytuje teleme­­trická data pro sledování nefunk­­čních požadavků a prevenci problémů (např. počet reques­­tů­/min, max. a avg. délka odpovědi na request, aj.). Konvence a mechanismy je vhodné stanovit společně s provoz­ovateli aplikace (např. service ownery).

Jak technicky řešit code review?

Téměř všechny VCS dnes podporují větve a pull-requesty, jejichž kombinací je možno technicky nástrojem řešit provádění code review.
Základem je izolace prováděné změny do samostatné větve oddělené od release větví aplikace, její jasná identifikace a po implementaci změny vytvoření pull-requestu jako žádost o review a o začlenění Vaší změny do aplikace. Standardizace tohoto postupu je závislá na zvoleném VCS workflow, které je vhodné v týmu definovat a dodržovat.
Využití technického řešení s sebou nese výhody jako evidence historie, podpora online remotingu, vyšší automatizovanost např. napojením výsledků analyzátorů, automatizaci.
Návod pro BitBucket, Github a různá worflows.

Tento cheatsheet přines­la...

Pojďte s námi budovat moderní IT kulturu

       

Help Us Go Positive!

We offset our carbon usage with Ecologi. Click the link below to help us!

We offset our carbon footprint via Ecologi
 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Nature of Business and Accounting Cheat Sheet
          Accounting Principles and Business Transactions Cheat Sheet
          Conceptual Database Design Cheat Sheet