Fullstack CourseLearn by building
Back to week 4

Topic

Code review & feedback

Definition

Code review is a structured process where a change author submits a bounded diff for another person to evaluate against correctness, security, readability, and architecture before it merges, and constructive feedback frames issues as specific, actionable observations rather than judgments of the author.

In simpler words

Review is someone else checking a change against real criteria before it ships, and giving or receiving feedback well makes that process actually useful.

Use the same checklist mindset from this week when reviewing a teammate Nest PR — migrations, guards, DTOs, and contracts.

After this you can

  • Write a PR description that helps a reviewer verify a change quickly
  • Give specific, actionable review comments instead of vague ones
  • Distinguish a blocking issue from a stylistic preference
  • Respond to review feedback without treating it as personal

Making a PR reviewable

Definition

A reviewable pull request describes intent, scope, and verification steps clearly enough that a reviewer can assess correctness without re-deriving the author reasoning from the diff alone.

In simpler words

Tell the reviewer what changed, why, and how it was checked, instead of making them reverse-engineer intent from raw code.

A good description states the problem, the approach, what was explicitly left out of scope, and how it was verified, including which requests or tests were run.

Small, single-purpose PRs get reviewed faster and more carefully than large ones.

PR description shape

## What
Add priority enum with a filter query param.

## Why
Support triage sorting.

## Verified
- Migration applied and rolled back cleanly
- POST/GET tested via Postman as member and admin
- OpenAPI reflects the new field

A reviewer can verify claims instead of guessing intent.

Giving and receiving feedback

Definition

Actionable feedback identifies a location, states a concrete consequence, and suggests a direction; receiving feedback well treats comments as evaluation of the code, not the author.

In simpler words

Say what is wrong, where, and why it matters — then respond to the technical point.

Label blocking issues (bugs, auth holes, missing migrations) vs non-blocking preferences.

Ask clarifying questions instead of guessing tone.

Keep in mind

  • Write the PR description a reviewer needs, not the one that is fastest to type.
  • Point at a specific line, name the consequence, and suggest a direction.
  • Label feedback as blocking or non-blocking so authors can prioritize.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥ 80% (enforced by the API) to save progress.

Checking your session…

10 questions · concept 3 · syntax 2 · practical 3 · logic 2

Concept1. Which statement best defines code review and feedback?
Syntax2. Which code-level choice matches code review and feedback?
Practical3. A reviewer spots a bug related to code review and feedback. What is the right fix?
Logic4. Which reasoning correctly explains code review and feedback?
Concept5. Which boundary does correct use of code review and feedback preserve?
Practical6. What is the safest next step when applying code review and feedback?
Syntax7. Which implementation direction matches the rule for code review and feedback?
Logic8. Which consequence follows from applying code review and feedback correctly?
Concept9. Which claim about code review and feedback is true in this Nest + Postgres monorepo?
Practical10. Which team practice best demonstrates code review and feedback?