# Code Review Walkthrough — Learn by Doing

## Before We Begin

Code review works best when we treat feedback as a collaborative improvement, not a judgment. The goal is better code and shared learning—not winning an argument.

**Diagnostic question:** When you've given or received code feedback, what made it feel helpful? What made it feel adversarial?

**Checkpoint:** You can name one behavior that makes feedback land well and one that makes it land poorly.

---

## Step 1: Prepare Your Mindset

Before reviewing or being reviewed, set the right frame.

**Task:** Think of the last time someone critiqued your work (code or otherwise). How did you feel? What made it easier or harder to accept?

**Question:** Why do you think code review comments can feel personal, even when they're about the code? What's one way to mentally separate feedback from identity?

**Checkpoint:** The user should recognize that feedback targets the work, not the person, and that separating the two reduces defensiveness.

---

## Step 2: Write a PR Description

Good descriptions make reviews faster and more accurate.

**Task:** Pick a small change you've made recently (or imagine one). Write a PR description with "What", "Why", and "How" sections. Keep it under 10 lines.

**Question:** What information would a reviewer need that isn't in the diff itself? Why does "Why" matter as much as "What"?

**Checkpoint:** The user should include context (what problem it solves), rationale (why this approach), and enough technical detail for a reviewer to verify the change.

---

## Step 3: Turn a Vague Comment into a Good One

Practice giving specific, constructive feedback.

<!-- hint:code language="javascript" highlight="2,4" -->

**Task:** You see this code in a PR:

```javascript
function findUser(id) {
  for (let i = 0; i < users.length; i++) {
    if (users[i].id === id) return users[i];
  }
  return null;
}
```

Write three possible review comments: one vague, one specific but unhelpful, one specific and constructive (with a suggestion).

**Question:** What makes the third comment more useful? How would it change the author's next steps?

**Checkpoint:** The user produces a comment that explains the issue, why it matters, and suggests an improvement (e.g., `find()` or a Map for repeated lookups).

---

## Step 4: Prioritize Feedback

Not all feedback is equal.

<!-- hint:buttons type="single" prompt="What's the priority of 'API key hardcoded'?" options="Blocking,Should fix,Nit" -->

**Task:** Given these hypothetical review comments, classify each as "blocking", "should fix", or "nit":

1. "There's a potential null reference on line 42 when `response` is undefined."
2. "Consider renaming `x` to `userCount` for clarity."
3. "This API key is hardcoded; it should come from env."
4. "I'd use `forEach` instead of `for` loop here."

**Question:** What criteria help you decide whether something blocks merge vs is optional?

**Checkpoint:** The user correctly prioritizes: (1) blocking, (2) nit, (3) blocking, (4) nit — and can explain why security and correctness trump style.

---

## Step 5: Respond to Feedback

Practice receiving feedback gracefully.

**Task:** Imagine a reviewer wrote: "This function is too long and does too much. Hard to test."

Write two responses: one defensive, one constructive. The constructive response should either (a) ask a clarifying question, or (b) propose a concrete next step.

**Question:** What does a "constructive" response accomplish that a defensive one doesn't?

**Checkpoint:** The user's response acknowledges the concern and either asks for specifics or proposes refactoring into smaller, testable functions.

---

## Step 6: Build a Review Checklist

Make reviews consistent and thorough.

<!-- hint:list style="cards" -->
<!-- hint:card type="tip" title="Best practices: correctness first, then tests, then readability" -->

**Task:** Create a personal checklist of 5–7 items you'll check on every PR you review. Mix correctness, readability, and process (e.g., "PR has tests").

**Question:** How might a checklist change your review behavior? What might you overlook without one?

**Checkpoint:** The user's checklist covers at least correctness, tests, security considerations, and readability. They can explain why each item matters.