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.

reviewer - Kvalif­ikovaná osoba provád­ějící review.
reviewee - 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 validuje).

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

Odevzd­áváme hotový výsledek
Reviewee 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 reviewee, který následně zapracuje připomínky.
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á validace. Standardně se používá pří technice "­pár­ová­ní" (pair-­pro­gra­mming).

Doporučení pro peer-r­eview

Respekt, slušnost a otevřenost je nutný předpoklad pro provádění review.
Review ideálně provádějte na menším rozsahu a častěji.
Review neodkl­ádejte, ale také nedělejte předčasně.
Review musí být efektivní, omezte čas na nutné minimum.
Zaměřte se na důležité, nezano­řujte se do přílišných argume­ntací a detailů.
Nekont­rol­ujte, co zkontr­oluje stroj.
Dohodněte si pravidla pro provádění review ve svém týmu.
Nevymý­š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).
Srozum­ite­lnost 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.
Defensivní 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­perace.
Otesto­vanost
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ář.
Telemetrie - logování a monitoring
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

       
 

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