Code review basics

What review is for

A code review is a teammate reading your pull request before it merges. It's not a trial. Teams review everything, including the tech lead's work, because it reliably catches what authors can't see:

• Bugs and edge cases: "what happens here when the list is empty?"
• Clarity: if the reviewer can't follow it, the next maintainer can't either.
• Consistency: naming, structure, and conventions matching the codebase.
• Knowledge spread: after review, two people understand this change, not one.

Reviewers comment on specific lines of the PR's diff, exactly the diff reading you practiced in lesson 3-2. Comments range from blocking ("this breaks empty carts") to take-it-or-leave-it nitpicks, often marked "nit:".

The robots review first: CI

On real teams, opening or updating a pull request automatically triggers CI (continuous integration): a server checks out your branch and runs the project's automated checks — the test suite, style checkers, sometimes a full build. The PR page shows the result as a green check or a red ✗, and most teams configure GitHub to refuse the merge button while checks are red.

The reason for the division of labor: reviewer attention is the scarcest resource on a team, so machines catch the mechanical problems (broken tests, formatting) and humans spend their time on what machines can't judge — design, naming, edge cases. In practice that means a red ✗ is your signal to fix and push again before asking anyone to look; requesting review on a red PR wastes a teammate's pass through it.

Getting through review smoothly

Responding to feedback: make the fixes as new commits on the same branch and push. The PR updates automatically, there's no "resubmit", the conversation just continues on the new code. Reply to each comment, and when you disagree, say why, reviews are discussions, not orders.

The single biggest kindness: keep PRs small. A 100-line PR gets a careful review in minutes. A 3,000-line PR gets a tired skim and a week of delay. Small, focused branches (one bug fix, one feature slice) are the team-scale payoff of the small-commits habit from lesson 2-3.

Write the description for the reviewer: what changed, why, and how you tested it. You're saving them the archaeology.