Quantifying Continuous Code Reviews

<p>Code reviews have become one of the most widely agreed-on best practices for software<br>quality. In a code review, a human reviewer manually assesses program code and denotes<br>quality problems as review findings. With the availability of free review support tools, a<br>number of open-source projects have started to use continuous, mandatory code reviews.<br>Even so, little empirical research has been conducted to confirm the assumed benefits<br>of such light-weight review processes. Open questions about continuous reviews include:<br>Which defects do reviews solve in practice? Is their focus on functional, or non-functional<br>problems? What is the motivation for changes made in the review process? How can<br>we model the review process to gain a better understanding about its influences and out-<br>comes?<br>In this thesis, we answer the questions with case studies on two open-source systems<br>which employ continuous code reviews: We find that most changes during reviews are<br>code comments and identifier renamings. At a ratio of 75:25, the majority of changes is<br>non-functional. Most changes come from a review suggestion, and 10% of changes are<br>made without an explicit request from the reviewer. We design and propose a regression<br>model of the influences on reviews. The more impact on the source code an issue had, the<br>more defects need to be fixed during its review. Bug-fixing issues have fewer defects than<br>issues which implement new functionality. Surprisingly, the number of changes does not<br>depend on who was the reviewer.</p> <p>