Which code review metrics should you track and analyze? (original) (raw)

Last updated on Jul 15, 2024

Code review is a vital practice for improving the quality, security, and maintainability of software projects. It involves checking the code changes made by other developers before they are merged into the main branch or released to production. But how do you measure the effectiveness and efficiency of your code review process? What are some of the metrics and indicators that you can track and analyze to optimize your code review performance and outcomes? This article explores some of the most useful code review metrics and indicators that you can use to monitor and improve your code review skills.

Key takeaways from this article

Implement pull request templates:
Standardizing the review process with templates ensures that reviewers understand the intended impact of code changes, leading to more relevant feedback and a clearer evaluation of code quality.
Incorporate well-designed tests:
Tests can catch issues that arise from the interactions between new and existing code—a common blind spot in reviews that focus only on recent changes.

This summary is powered by AI and these experts

Steve Hickman Privacy by Design
Ben Abrams Supreme Unicorn Hunter of Planet Earth…
Code reviews rarely reveal bugs that result from the interaction of the changes with code that wasn’t changed. Why? Because reviewers rarely think about those possibilities- and many may not understand the code well enough to even guess at them. Further, reviews only capture attention at a moment in time. Well designed tests address both these problems.
All changing code should be reviewed this should be enforced with branch protections & CODEOWNERS. I agree with Steve, I think testing coverage is more meaningful metric in preventing bugs in unreviewed code. This metric should pretty much always be 100% for the lines of change.

Review Participation

Review participation is the ratio of reviews performed by a developer to reviews requested by a developer. It is a metric that reflects how active and collaborative a developer is in the code review process. A high review participation means that a developer is contributing to the code quality and knowledge sharing of the team by reviewing other developers' code changes and providing constructive feedback. A low review participation means that a developer is either too busy, too reluctant, or too isolated to engage in the code review process and benefit from the peer learning and improvement opportunities. You can calculate the review participation by dividing the number of reviews performed by a developer by the number of reviews requested by the same developer in a given period.

Review Participation is a vital metric for understanding the collaborative dynamics and overall health of a development team. - Encourages team members to share knowledge and best practices. - Promotes a sense of ownership and accountability among developers. - Diverse perspectives help in identifying bugs and potential improvements. - Constructive feedback leads to continuous learning and skill enhancement. - Prevents overburdening of a few developers with review tasks. - Streamlines the code review process, reducing bottlenecks.

Review Speed

Review speed is the average time it takes for a code change to be reviewed and approved by another developer. It is a metric that indicates the speed and responsiveness of the code review process. A high review speed means that the code review process is efficient and agile, allowing the developers to deliver their code changes to the main branch or production quickly and smoothly. A low review speed means that the code review process is slow and sluggish, causing delays, bottlenecks, and frustrations for the developers and affecting the delivery time and quality of the software. You can calculate the review speed by dividing the total time spent on reviewing code changes by the number of reviewed code changes in a given period.

This metric is crucial in larger codebases where `CODEOWNERS` have different teams and it take multiple reviewers to get it pushed. I do find it important to remove some of the top results to account for automation and people who are reviewing "too quickly" (as in not actually reviewing but giving an `LGTM` which requires a separate conversation). One of the things we recently did at our org to improve this metric was to allow a comment on the pull request `BOTNAME coderereview` which would get the list of required `CODEOWNERS`, lookup their slack channel, and post a request for review.

Review Depth

Review depth is the average number of comments or issues raised by a reviewer per code change. It is a metric that reflects how thorough and comprehensive the code review process is. A high review depth means that the reviewers are paying attention to the details and logic of the code changes and providing valuable feedback and suggestions to improve the code quality, readability, and maintainability. A low review depth means that the reviewers are skimming or overlooking the code changes and providing superficial or irrelevant feedback that does not help the code improvement or learning. You can calculate the review depth by dividing the total number of comments or issues raised by reviewers by the number of reviewed code changes in a given period.

I find this to be an interesting metric, sometimes I find it hard to make sense of it without zooming in. I would generally say that even engineers who are very thorough have two kinds of reviews. This usually centers around the perceived complexity, testing, and trust that the author understands the impact of their changes. Sometimes we get massive deltas that really have little or no impact. If we trust the tests and the author it can be a simple approval (which is a state of a comment review) indicating such and not that you have given it a through review. When we and the author agree about the complexity we give it a thorough review, this is where this metric does very well in quantifying the original points of the author.

Review Quality

Review quality is the degree to which the code review process achieves its intended goals of improving the code quality, security, and maintainability, as well as enhancing the team collaboration, communication, and learning. It is a subjective and complex metric that depends on various factors and criteria, such as the code review guidelines, standards, and expectations, the feedback style and tone, the code review tools and platforms, and the team culture and dynamics. Review quality can be measured by using different methods and sources, such as surveys, interviews, feedback forms, ratings, ratings, metrics, or indicators, that capture the satisfaction, perception, and experience of the developers involved in the code review process.

I love these "squishy metrics" that are little more than user experience interviews in various forms as they are less susceptible to be "gamed".

Review Impact

Review impact is the extent to which the code review process influences the final outcome and performance of the software project. It is a metric that evaluates the value and benefits of the code review process for the software product, the users, and the stakeholders. A high review impact means that the code review process has helped to reduce the number of bugs, errors, or vulnerabilities in the software, increase the software functionality, usability, and reliability, and enhance the user satisfaction, retention, and loyalty. A low review impact means that the code review process has not made a significant difference or improvement to the software quality, security, or maintainability, or has even introduced new problems or issues that affect the software functionality, usability, or reliability. You can measure the review impact by using different methods and sources, such as testing, debugging, monitoring, analytics, feedback, or reviews, that track and assess the software quality, security, and maintainability metrics and indicators.

In my experience this is the most important aspect even if I am not sure I know of an easy and good metric to measure this TBH. At my organizations we use pull request templates to help the reviewer outline what the impact is. This reduces the burden on the reviewer to divine what the intended impact is vs what the actual impact the reviewer sees from the deltas and other artifacts on the pull request.

Rate this article

We created this article with the help of AI. What do you think of it?

Thanks for your feedback

Your feedback is private. Like or react to bring the conversation to your network.

Report this article

See all