Information Needs in Contemporary Code Review

Abstract

Contemporary code review is a widespread practice used by software engineers to maintain high software quality and share project knowledge. However, conducting proper code review takes time and developers often have limited time for review. In this paper, we aim at investigating the information that reviewers need to conduct a proper code review, to better understand this process and how research and tool support can make developers become more effective and efficient reviewers. Previous work has provided evidence that a successful code review process is one in which reviewers and authors actively participate and collaborate. In these cases, the threads of discussions that are saved by code review tools are a precious source of information that can be later exploited for research and practice. In this paper, we focus on this source of information as a way to gather reliable data on the aforementioned reviewers' needs. We manually analyze 900 code review comments from three large open-source projects and organize them in categories by means of a card sort. Our results highlight the presence of seven high-level information needs, such as knowing the uses of methods and variables declared/modified in the code under review. Based on these results we suggest ways in which future code review tools can better support collaboration and the reviewing task. Preprint [

Not all bugs are the same: Understanding, characterizing, and classifying bug types

“…Finally, when considering the DAC reported in Figure 7, we observe that the majority of bug types have a similar delay after that the corresponding patches have been submitted. Most likely, this heavily depends on the processes adopted within the projects to control for the soundness of a patch: for instance, most of the modern projects perform code review activities of all the newly committed code changes, and have standard procedures to assess the validity of the change before integration in the code base [64]. The only exception to this general discussion is related to the configuration-issue, which takes up to 33 hours to be integrated: however, given previous findings in literature [6,53,82], we see this as an expected result because configuration-related discussions generally trigger more comments by developers since a change in configuration files might impact the entire software project.…”

Tools, processes and factors influencing of code review

“…Code review is a well-established software engineering practice [7], where developers submits their code modifications to peers to judge its eligibility to be integrated into the main project codebase [18]. And a software quality assurance activity, that reviews aim to identify defects and improve the quality of the source codes, ultimately, the main purpose of code reviews is to produce a better software product [4].…”

“…And a software quality assurance activity, that reviews aim to identify defects and improve the quality of the source codes, ultimately, the main purpose of code reviews is to produce a better software product [4]. Using knowledge transfer of design and implementation solutions applied by others [7]. Code review is the manual or automatic assessment of source code by humans or software, a manual inspection of source code will be done by developers, and this helps in improving the quality of software projects [10].…”

“…The process of analyzing and verification source code written by another developer on the project to judge whether it is of sufficient quality to be merged into the master project repository [6]. The code review process depending on the components of a review as provided by code review tools [7]. These processes include: code review tools provide an ID and a status for each code review, which are used to track the code change and know whether it has been merged and also allow authors to include a textual description of the code change, to provide reviewers with more information on the rationale and behavior of the change.…”

“…This meta-information includes author and committer of the source code modification, commit ID, origin commit ID, and modification ID, that can be used to track the submitted modification over the history of the project, reports about the information on who are the reviewers assigned for the inspection of the submitted code change, lists the source code files modified in the commit, Finally, the root component for source code review tool and that involves most collaborative parts, reports about the discussion that the author and reviewers are having on the submitted code change. Reviewers can ask clarifications or recommend improvements to the author, who can instead reply to the comments and propose alternative solutions [7]. Figure 2 presents general processes of code review.…”