2、每小时低于 300–500 LOC 检查率的目标

　　定义

　　检查率：我们能够多快地评审代码呢？通常以每小时 kLOC（千代码行）来评价。

　　缺陷率：我们能够多快地发现缺陷呢？通常以每小时缺陷数来评价。

　　缺陷密度：给定量的代码之中我们能够发现多少的缺陷呢（而不是它们有多少）？通常以每 kLOC 中发现的缺陷数来评价。

　　您要花点时间进行代码评审。快速评审并不总是好的。我们的研究结果显示检查率低于“300-500 LOC/小时”时，可以得到优化的结果。根据所作的决定，评审者的检查率有很大的变化，算是相似的代码开发者、评审者，文件和评审规模，也存在巨大的差异。

　　为了找到优化的检查率，我们将 缺陷密度 与评审者检查代码的 速度 进行了比较。得到的结果再一次落在了我们的预料之中：如果在评审您不花足够的时间，那么您不会发现太多的缺陷。如果评审者面临大量代码的压力，那么他不会每一行代码投入相同的注意力。他不能研究同一位置处更改的所有版本。

　　所以，多快算是太快呢？图 2 显示了答案：服务器端每小时超过 400 LOC 的评审速度会降低效率。而每小时 1000 LOC 的速度，您可能已经推出了，以这样的速度评审员可能根本都没有细看代码。

图 2. 评审量超过 500 行代码时检查效率会下降了

 

　　3、花足够的时间进行适当缓慢的评审，但是不要超过 60-90 分钟

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

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

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

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

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

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

 

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