Part 0 · 2 chapters · ~12 min

What Review Is For

The purposes of code review in order of value (correctness, design, tests, knowledge sharing, standards), what review is not (a gate for perfection, a place for style wars, a substitute for testing), and what research at Microsoft and Google found reviews actually achieve.

1

Five purposes, ranked

Studies of code review at Microsoft (Bacchelli and Bird, 2013) found that while people expect review to find defects, much of its real value is knowledge transfer, team awareness and better solutions. Google's guidance puts it simply: approve a change once it definitely improves the overall code health, even if it is not perfect.

WHAT REVIEW IS FOR, IN ORDER
spend attention from the top down
1. correctnessdoes it do what it claims, safely? money, data, security2. designright place, right abstraction, will it be easy to change?3. testswould they catch a regression?4. knowledge sharingdoes someone else now understand this area?5. standardsnaming, consistency (most of this belongs to linters)
swipe the figure sideways, or tap expand for full screen
1/5
correctness
First: does the change do what it says, and is it safe? Money paths, data migrations, auth checks, concurrency, error handling. A bug here costs more than every other category combined.
does it work, and is it safe?money, data, security first
2

What review is not

review is notbecauseinstead
a quest for perfectionevery round of nits delays value and teaches people to send fewer PRsapprove when it improves the code; follow up on minor things
a formatting debatemachines do it better and without feelingsPrettier, Biome, gofmt, Black, ruff, rubocop in CI
the main defence against bugsreviewers miss most bugs in large diffstests, types, static analysis, staged rollouts
a place to redesign the featuretoo late; costly for everyonedesign docs and early conversations for big changes