Lazy code review is a review performed with insufficient examination to identify relevant defects, risks, or improvement opportunities reliably. It may be rushed, superficial, or improperly bypass the team’s process. section 7.1.1
Common workplace patterns include:
- Approving a huge pull request with an automatic “LGTM” after barely examining its files and changes. section 7.1.1
- Using an urgent production hotfix to bypass review, then allowing emergency workarounds to become normal. section 7.1.1
- Skimming code or pressuring reviewers toward approval because review speed or approval rates are treated as targets. section 9.2.5
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 review-time, participation, and code-churn measures as signals for investigation rather than goals that encourage rushed approvals. section 9.2.5
