Exploring Code Review and Churn
This is the first post in a series about measuring the software engineering process using data from the AutoDev Analytics benchmark. In general, we look at how source code connects to outcomes and how dev processes can impact that. In this post we’ll look at how code review and code churn interact. Read more here about how we constructed the benchmark.
When we started looking at how a code base changes over time we found strong, if unsurprising, links between code churn and code review. Some highlights we learned from the thousands of projects and hundreds of millions of lines of code in our benchmark:
These stats sketch a strong link between code review and churn, as well as a big opportunity to improve the level of engagement with the code review process. Of course, there’s a lot of nuance in development processes and some degree of code churn is natural. In the rest of this post we’ll dig into some details to help illustrate what’s really going on.
Let’s take a look at the Analytics report for dotnet/diagnostics, the source repository for a variety of .NET diagnostics tools, to help dig into how code churn in a code base correlates with code review. The benchmark has similar reports for thousands of other popular projects.
