永远不要对一个原型代码评审超过 60-90 分钟

　　我们应该讨论，为了得到更好的结果，不应该过快地评价。但是您也不应该在一个位置花太多的时间。大约 60 分钟后，评审者会感到疲劳，于是不会找到额外的缺陷了。这个结论得到了许多其他研究的支持。实际上，根据我们的常识，当人们从事注意力高度集中的活动时，性能状态在 60-90 分钟之后会降低了。考虑到人体方面的限制，评审者在性能降低之前，不能评审超过 300~600 行的代码。

　　但反过来说，评审代码所花的时间不得低于五分钟，算代码只有一行也是如此。通常来说，单行的代码也会影响到整个的系统，所以花上五分钟时间去检查更改可能造成的结果是值得的。

　　4. 确定在评审开始之前代码开发者已经注释源代码了

　　在评审开始之前代码开发者可能消除大多数的缺陷，这一点我们将会看到。如果我们需要开发人员双倍地检查他们的工作，那么评审可能更快地完成，而不用再去折中考虑代码质量的问题。我们所知，这种特定的想法尚未得到研究，所以我们在 Cisco 研究期间对其进行了测试。

图 3. “代码开发者准备”对缺陷密度的震撼性效果

　　“代码开发者准备”说的是代码开发者在评审之前要先注释他们的源代码。我们发明了这个术语，以描述研究中所评价的特定行为模式，大约 15% 的评审会阻止代码开发者这样做。注释会指导评审者进行变更，显示首先必须要查看的文件，并找到每一次代码更改的原因。这些注释不是代码之中的评论，而只是给其他评审者看的评论。

　　我们的理论是，因为代码开发者需要重新考虑，并解释注释过程中所发生的更改，所以代码开发者需要在评审开始之前找出许多缺陷，以让评审变得更加有效。如此，评审过程将会产生低密度的缺陷，因为更少的错误(bug)剩余了。很明显，与没有代码开发者准备的评审相比，代码开发者准备之后的评审有更少的缺陷存在。

　　我们还考虑过一个悲观的理论，以解释错误(bug)的低发现率。是不是当代码开发者在作出一项评论时，评审者会有偏见，或者自鸣得意，这样不能尽可能多地发现错误(bug)了呢?我们随机抽查了 300 个评审者进行研究，结果证实评审者在评审代码时确实非常小心，更少的错误(bug)被发现了。

　　5. 为代码评审创建可定量化的目标，并获取制度，这样您可以改进流程了

　　有了项目，您该决定代码评审过程的目标，以及怎样评价效率问题了。当您在定义特定的目标时，您能够决定同行评审是否真的达到了您所需要的结果。

　　好从外部性的制度开始，例如“将支持访问降低 20%”或者“使开发引入的缺陷百分比减半”。这些信息使您能够更好地看清，从外部视角来看，代码能够做些什么，您还需要一个可定量化的评价手段，而不是“修复更多错误(bug)”的模糊目标。

　　但是，在外部制度显示结果之前需要花上一段时间。例如，支持性访问将不会得到影响，直到新的版本得到发布并交到客户手中为止。所以查看内部性流程工具，以得到发现多少缺陷，缺陷是问题所在，以及开发人员在评审上所花时间的清晰结果。代码评审的常见内部性制度是检查率 ，缺陷率，以及缺陷密度。

　　考虑一下只有自动化或者紧密控制的流程，才能给您带来可重复的代码;人类并不擅长记住启动或者终止计时器。为了得到好的结果，您要使用能够自动收集代码的代码评审工具，这样用于流程改进的关键代码是精确的了。

　　为了改进和提高您的流程，您可以收集代码并组合流程，以查看更改是如何影响结果的。很快，您将会知道什么工作适合您的团队了。

　　6. 使用检查表，因为它能极大地影响代码开发者和评审者的结果

　　使用检测表对于评审员非常重要，如果代码开发者忘记了某项任务，评审员也同样可能忘记。

　　我们极力推荐您使用检查表，来确定您可能会忘记的事情，它对代码开发者和评审者都有用。忽略是难发现的缺陷;毕竟，评审不在那里的东西是很困难的一件事。检查表是解决这个问题的好方式，因为它会提醒评审者和代码开发者花点时间去考虑一下可能被遗忘的事情。检查表还会提醒代码开发者和评审者确定所有的错误(bug)都得到了处理，软件功能已经通过了无效值测验，而且已经创建了单元测试。

　　另外一个有用的概念是个人检查表 。每个人一般都会犯 15-20 个错误(bug)。如果您注意到了一些典型的错误(bug)，那么您可以开发自己的个人检查表(Personal Software Process，Software Engineering Institute，以及 Capability Maturity Model Integrated 也都推荐该实践方式)。评审者将会完成决定一般性错误(bug)的工作。您所应该做的，是拥有一个简短的检查列表，一般都是您容易遗忘的事情。

　　一旦您开始在检查列表中记录自己的缺陷，那么您会少犯错了。规则将不断出现在您的脑海中，然后您的错误(bug)率会下降了。这种情况我们将会发现它反复出现。

　　提示：

　　如果您想要得到关于检查列表的更多具体信息，那么您可以得到本文代码开发者所写书籍的免费拷贝，这本书为 Best Kept Secrets of Peer Code Review，网址为www.CodeReviewBook.com。

　　7. 确认缺陷得到了修复

　　是的，这种“佳实践”看起来好像是没有脑子的。如果您遇到了评审代码以找到缺陷的所有问题，那么修复它们变得顺理成章了!现在许多评审代码的团队没有一种好的办法，去追踪评审期间找到的缺陷，并确保评审完成之前错误(bug)确实得到了修复。确认电子邮件之中的结果，或者实时评审是非常困难的。

　　记住这些错误(bug)通常不是在 Rational Team Concert 日志中输入的，因为在代码发布给 QA 之前发现了这些错误(bug)。所以，什么是代码在贴上“全部解决”标志之前确认缺陷的好办法呢?我们建议使用好的协作性评审软件，与 Rational Team Concert 相集成，以追踪评审之中所发现的缺陷。有了正确的工具，评审员可以记录错误(bug)，并在必要时与代码开发者进行讨论了。然后代码开发者会修复问题，并通知评审者，而评审者必须确认每个问题都得到了解决。工具应该追踪评审期间所发现的问题，并确保直到所有的错误(bug)被评审者修复 才完成评审(或者作为稍后解决的单独工作项追踪)。工作项只有在评审完成时才能通过。