The most popular code review tools (e.g., Gerrit and GitHub) present the files to review sorted in alphabetical order. Could this choice or, more generally, the relative position in which a file is presented bias the outcome of code reviews? We investigate this hypothesis by triangulating complementary evidence in a two-step study. First, we observe developers' code review activity. We analyze the review comments pertaining to 219,476 Pull Requests (PRs) from 138 popular Java projects on GitHub. We found files shown earlier in a PR to receive more comments than files shown later, also when controlling for possible confounding factors: e.g., the presence of discussion threads or the lines added in a file. Second, we measure the impact of file position on defect finding in code review. Recruiting 106 participants, we conduct an online controlled experiment in which we measure participants' performance in detecting two unrelated defects seeded into two different files. Participants are assigned to one of two treatments in which the position of the defective files is switched. For one type of defect, participants are not affected by its file's position; for the other, they have 64% lower odds to identify it when its file is last as opposed to first. Overall, our findings provide evidence that the relative position in which files are presented has an impact on code reviews' outcome; we discuss these results and implications for tool design and code review. Data and materials: https://doi.org/10.5281/zenodo.6901285
翻译:最流行的代码审查工具( 例如 Gerrit 和 GitHub) 展示了要按字母顺序排序的文档。 是否能够做出这样的选择, 或者更笼统地说, 显示文件的相对位置 。 我们通过在两步研究中三角补充证据来调查这一假设 。 首先, 我们观察开发者的代码审查活动 。 我们分析了 GitHub 上138个流行的 Java 项目的 219, 476 号拉动请求 (PRs) 的审评评论 。 我们发现, 早些时候在 PR 中显示的文件比以后显示的文件收到更多的评论 。 在控制可能的混杂因素时, 能否做出这样的选择 。 例如, 是否有讨论线索或文档中添加的线条的相对位置 。 其次, 我们测量文件位置对在代码审查中的缺陷的影响 。 招聘了 106名参与者, 我们进行在线控制实验, 测量参与者在发现两个不相干的缺陷时的表现 。 参与者被分配到两种处理缺陷文件的位置的处理办法之一 。 对于一种类型,, 参与者不会受到文件位置的偏差 。 。 在文件位置上的位置上, eurve e e e lex e e e e e e e 。