liveBook · Manning

Code review usefulness

As explained in "Looks Good to Me"

The degree to which code reviews achieve their intended outcomes, such as finding problems and improving software quality.

Code review usefulness measures whether reviews find potential problems, improve quality, and support feedback without turning approval speed into the goal. Approval rates and review time can create harmful shortcuts when teams optimize for favorable numbers. section 9.2.5 section 9.3

Treat review metrics as signals, then interpret them through team context:

  • Code churn shows how much code is changed, reworked, or reverted after review. section 9.2.5
  • Review time can indicate timely feedback and manageable pull requests, but slower cycles may reveal bottlenecks or unclear requirements. section 9.2.5
  • Review participation and pull request size add context that approval rates alone cannot provide. section 9.3
Table 9.1 Code review metrics
Metric
What does it measure?
How to measure it
Effect
Code churn
How often a given piece of code is changed/ reworked after a review
Track lines of code added, deleted, and reverted after a review.
High churn can suggest overly stringent reviews or submitted code that is subpar/unclear.
Low churn can indicate improved quality and legibility.
Review time
How long an average code review lasts
Track the time between opening a PR and merging it.
Faster review cycles can indicate timely feedback, greater alignment between author and reviewer, and manageable PR sizes.
Slower review cycles can indicate communication bottlenecks, larger PR sizes, and a lack of clarity in requirements.
Review participation
How active team members are in code reviews
Track the number of reviews participated in, comments left, and average review time per developer.
High rates suggest a more collaborative culture and thorough individual reviews.
Low rates can suggest uneven PR workload distribution, communication and feedback difficulties, or less engagement in reviews overall.
PR size
The average size of a pull request
Track the number of files/lines of code a PR has.
Larger sizes can indicate unclear work tickets or acceptance criteria.
Smaller sizes can suggest better planning and alignment on work tickets.

Use the code review metrics table to compare what each metric measures, how to track it, and what high or low values may suggest. section 9.2.5

How "Looks Good to Me" covers it

How deep it goes
Defines four review signals and their interpretations, then stops short of treating any metric as a complete explanation.
Examples
Uses code churn, review time, review participation, pull request size, approval rates, and production problems as evidence.
What you can do after
Evaluate review efficacy by combining metric trends with contextual team discussion rather than optimizing a single number.
How it connects
Connects code reviews with feedback culture, pull request size, code churn, review time, review participation, and DORA metrics.

Related concepts

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.