code-review

Topics in the source

• Code review
• 1. Understand the intent before reading the diff
• 2. Read the change in dependency order
• 3. Hunt in priority order
• 4. Verify before reporting
• 5. Report ranked, with the fix
• What not to do

A review is a search for the ways this change fails in production, ranked by how badly. It is not a style pass. Style is the lint job's work — if you spend the review on formatting, you have used up the reader's attention on the cheapest possible findings. The bar for reporting: could you write the input that makes this go wrong? If not, you have a question, not a finding. Say it as a question. Read the PR description, linked issue, or ask. Reviewing a change without knowing its goal produces suggestions that fight the author's purpose. Then decide what should have changed. Files you expected to see and don't are the highest- yield finding in any review — a new state field with no migration, a new branch with no test, a new error path with no logging. Done when: you can state the intent in a sentence, and you have a list of what you expect the diff to touch. Not top to bottom, and not alphabetically, the order the tool shows you is meaningless. Start at the data model or interface, then the logic, then the callers, then the tests. Meaning flows that direction and reviewing against the flow means re-reading everything twice. Done when: you have read every changed hunk, including the

This is an excerpt. Refer to the complete source and its current requirements.