我们的理论是，因为代码开发者需要重新考虑，并解释注释过程中所发生的更改，所以代码开发者需要在评审开始之前找出许多缺陷，以让评审变得更加有效。如此，评审过程将会产生低密度的缺陷，因为更少的错误（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）率会下降了。这种情况我们将会发现它反复出现。

　　7、确认缺陷得到了修复

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

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

　　如果您真面临着搜索错误（bug）的烦恼，那么请确认您已经将它们全部安装了！

　　既然您已经学会了代码评审 流程 的佳实践方式，那么我们接下来将会讨论一些社会效应，以及怎样管理它们以获得佳的结果。

　　8、培养良好的代码评审文化氛围，在这样的氛围中可以积极地评审缺陷

　　与其他我们能看到的大多数技术相比，代码评审对于真实团队构建能够发挥更大的作用，但是只是在管理人员能够以一种积极的，向上的，有技巧的方式进行交流时，这种优势才能发挥出来。将缺陷看做是不好的事物很容易（毕竟，它们是代码之中的错误（bug）），但是形成不好的缺陷检查态度，则会毁掉整个团队的努力，更不要说它会破坏错误（bug）检查过程了。

　　软件代码评审的要点在于，尽可能多的消除缺陷，不管是谁“导致”了错误（bug）。

　　管理人员必须建立缺陷是积极的这样的观点。毕竟，每一个缺陷的存在，都是改进代码的潜在机会，而错误（bug）评审过程的目的，在于使代码尽可能地完美。每一个被发现并解决的缺陷，都是客户以后不会看到的缺陷，也是 QA 人员不必花费时间去解决的问题。