一个结对 / 代码检查过程的学习案例

维多利亚大学软件工程组的 Peter C. Rigby 和 Daniel M. German 在 Margaret-Anne Storey 的指导下发布了一个 Apache 结对检查的学习案例，同时也将此文提交到了 FSE2007。这篇文章是 Peter 和 Daniel 发布于 2006 年的、对 Linux、GCC、Mozilla 和 Apache 的代码检查过程进行分析的“开源项目代码检查过程的一个初步检测 ”一文的姊妹篇。

新的案例学习对象是 Apache，目的是找出下面这些问题的答案：

• 过程：都是在执行哪些检查？是由哪些过程指导这些检查的？
• 频率和活动：检查的频率是多少？检查的频率是否与开发活动相关？
• 参与：有多少开发人员参与检查？在一次检查中有多少讨论？
• 尺寸：多大的构件才应该进行检查？
• 间隔：多长时间执行一次检查？
• 缺陷：有多少检查发现了缺陷？

在文章的答案里有两个在 Apache 项目使用并在 Apache 术语表中进行了定义的过程：CRT 和 RTC 的检查过程：

提交后检查（**CTR，Commit-Then-Review）：一个管理代码变化的策略，允许开发者随意更改代码，但允许后期否决。C-T-R 是一种在延迟决策（lazy consensus）中得出决定的方案，此模型在快速原型开发环境中很有效，但由于缺乏强制检查，可能会导致比 R-T-C 更多的问题。
检查后提交（**RTC，Review-Then-Commit）：提交策略，要求所有的改变得到一致性同意后方能被提交。

“一致性同意”表示要对某个做法进行投票，在结果中至少要有来自项目管理委员会（PMC）的三票赞成票，而且不能有反对票。

在分析检查过程时有一个关于两种检查过程各自优弱点的讨论。与 Apache 不同的是，在商业开发环境中倾向于使用 RTC 过程处理代码检查（这常常都是和风险管理的一个基本思想联系在一起的：宁可丢掉变化，也比让坏的变化进入你的代码库好得多）。这种讨论可以为增加 CTR 在商业开发环境中的生存能力提供令人信服的证据。在目前缺少 CTR 过程相关数据的情况下，对该过程进行的讨论分析也非常重要。

关于在多大的范围内进行分析检查，Apache（以及其它项目）使用“尽早检查、频繁检查”来表达，Apache 尤其以强调“尽可能高频率地执行检查，更短的间隔，更小的构件尺寸”与 Porter et al 的发现形成对比。针对较小的构件对不同的检查方式进行权衡，这也是文中一个重要的讨论主题。

另一个关键性的讨论是主要围绕着调解缺陷进行的：

对于常规的检查来说，讨论的主题就是缺陷。一个好的仲裁人是不会允许参与检查的人讨论任何缺陷以外的事情的。开发者必须修复这些缺陷并向仲裁人报告。

相比之下 Apache 的方法则是这样的：

检查者对缺陷本身并不感兴趣，而是对是什么导致缺陷以及如何修复感兴趣。讨论的中心马上由“发现缺陷”转到“如何修改缺陷”上来了。

文章的结论是“理想的时间是：当一个缺陷被发现时再去寻找解决办法，因为所有的参与者都要明白这个问题从何而来”，从中还发现“传统检查是不受时间约束的”与 Edward F. Weller 的“从三年数据检查中得到的启示 ”中示例的具体对比。

虽然文中数据收集的方法有些问题，与Apache 团队成员之间也缺乏互动，文章还是通过一些有趣的讨论来对照比较各种不同的检查方法，以说明无论是开源还是商业环境都需要建立一个检查方法。

查看英文原文： A case study of Apache peer/code review processes