liveBook · Manning

Self-review

As explained in "Looks Good to Me"

A review in which an author systematically examines their own proposed code changes before submitting them to other reviewers.

Before opening a pull request, stop being the implementer and become the reviewer. Take a real break, then inspect the change with fresh eyes. This catches obvious defects, missing context, unanswered questions, and unnecessary files before they create reviewer back-and-forth. section 2.4.2

Run a self-review by asking:

  • Did linters, formatters, static analyzers, and unit tests run, and were their obvious findings fixed? section 2.4.2
  • Does the change satisfy its acceptance criteria and include only relevant files? section 2.4.2
  • Can a reviewer understand the change from the code and pull-request information alone? section 2.4.2
  • Have edge cases, architectural fit, and likely reviewer questions been considered and documented? section 2.4.2

Before marking a pull request ready

Write down questions a reviewer might ask and answer them in the pull request. Revisit the change more than once, revising until the code and its context stand on their own. section 2.4.2

How "Looks Good to Me" covers it

How deep it goes
Provides a practical checklist and repeatable break-and-review procedure, stopping short of detailed automation implementation.
Examples
Uses reviewer questions about tests, files, context, edge cases, architecture, and unanswered pull-request questions.
What it assumes
Assumes responsibility for opening a pull request and familiarity with the proposed code change.
What you can do after
Evaluate changes independently, clarify hidden context, and submit a more reviewable pull request.
How it connects
Connects pull requests with code review, automated checks, acceptance criteria, edge cases, and software architecture.

This explainer was generated by Manning's knowledge graph from the text of "Looks Good to Me". The section links point to the parts of the book it draws on.