An empirical study of the impact of modern code review practices on software quality

Abstract

Software code review, i.e., the practice of having other team members critique changes to a software system, is a well-established best practice in both open source and proprietary software domains. Prior work has shown that formal code inspections tend to improve the quality of delivered software. However, the formal code inspection process mandates strict review criteria (e.g., in-person meetings and reviewer checklists) to ensure a base level of review quality, while the modern, lightweight code reviewing process does not. Although recent work explores the modern code review process, little is known about the relationship between modern code review practices and long-term software quality. Hence, in this paper, we study the relationship between post-release defects (a popular proxy for long-term software quality) and: (1) code review coverage, i.e., the proportion of changes that have been code reviewed, (2) code review participation, i.e., the degree of reviewer involvement in the code review process, and (3) code reviewer expertise, i.e., the level of domain-specific expertise of the code reviewers. Through a case study of the Qt, VTK, and ITK projects, we find that code review coverage, participation, and expertise share a significant link with software quality. Hence, our results empirically confirm the intuition Empir Software Eng that poorly-reviewed code has a negative impact on software quality in large systems using modern reviewing tools.

Aspect Oriented Re-engineering of Legacy Software Using Cross-Cutting Concern Characterization and Significant Code Smells Detection

“…DIT indicates the level of inheritance a class has, CBO numerically measures the extent to which objects are coupled with each other, CC value shows the complexity path existing in the source code and¯nally, LCOM indicates the cohesion of class constituents by examining the number of disjoint sets of the methods accessing similar instance variables; lower values posses compact modularization [31]. Generally, in evaluating the quality of object-oriented software, there is no standard threshold framework or¯xed criteria [58]. More importantly, quality attributes have variations and°uctuations according to nature and application of particular software [59].…”

Deriving a usage-independent software quality metric

“…The internal factors represent the set of factors that are artifacts of the software development process, and includes product parameters like size of the software and code complexity, process parameters like change entropy (distribution of changes with a component), human factors like the number of authors involved, number of reviewers with expertise, and code review parameters like number of reviews, number of reviewers etc. The impact of of these parameters are well known and have been used in multiple past studies [41,40,60,37]. However, the number of observed software failures also depend on external factors that are not part of the software development process.…”

Automatic Classification of Review Comments in Pull-based Development Model

“…Code review is employed by many software projects to examine the change made by others in source codes, find potential defects, and ensure software quality before they are merged [5], [12]. Traditional code review, which is also well known as the code inspection proposed by Fagan [7], has been performed since the 1970s.…”