11个高效的同行代码评审最佳实践

　　SmartBear Software 团队® 花费了数年时间去搜索已有的代码评审研究成果，并从来自超过 100 家公司的 6000 多名程序员那里，收集了“实践经验”。很显然，人们在评审代码时会发现一些错误(bug)，但是这种评审工作通常会花费大量的时间，因此变得不太实际。我们通过数十年的经验使用获得的信息，来创建轻量级代码评审的概念。通过使用轻量级代码评审技术，开发员只需要花费五分之一的时间就可以进行全面且规范的代码评审工作了。我们还开发了最佳实践的理论，以便部署实现评审的效率与价值。本文概括了以下的这些实践。

　　访问 developerWorks 社区上的 敏捷开发小组，在那里您将有机会与更多的开发人员一起交流敏捷开发最佳实践。

　　为了测试我们对代码评审及轻量级评审的结论，我们对代码评审进行了最大规模的研究工作。它涉及包含了2500 个代码评审案例，50 个程序员，及 Cisco 系统上320 万行的代码。在 10 个月的时间内，研究追踪了 MeetingPlace 产品团队，该团队拥有 Bangalore，Budapest 及 San José 方面的成员。

　　在研究开始时，我们要为这个团队创建以下的规则：

　　在检入到团队的版本控制软件之前，所有的代码都必须进行评审。

　　SmartBear 的 CodeCollaborator® 代码评审软件工具，应该用于精化，组织和改进所有的代码评审工作。

　　代码评审的全体会议是不支持的。

　　评审过程会得到工具的支持。

　　CodeCollaborator 会自动收集工具，提供评审层次和总结层次的报告。

　　根据我们的研究结果，总结了 11 项最佳实践

　　您应该警惕，平等代码评审(在该过程中，软件发布以确保质量之前，软件开发员会相互评审代码)会识别代码中存在的错误(bug)，鼓励协作，并使代码变得更有维护性。

　　但是很明显的一点是，有些代码评审技术是低效低能的。评审过程中的一些会议会占用时间，并抑制活力。严格的流程会扼杀创造力，但是松散的流程又意味着没人知道评审是否有效，甚至是否发生。而个人批评的社会效应，又会损伤士气。

　　本文描述了考虑效率时的 11 项最佳实践，科学研究和 SmartBear 领域内的经验证明轻量级同行评审是高效的。使用这些技术，可以确保代码评审能够改进代码 - 而不用占用开发员的时间。您可以使用最近的技术，来在 IBM® Rational Team Concert® 环境之中评审代码。

　　1. 一次评审量要低于 200–400 行代码

　　Cisco 代码评审研究(见于工具栏)显示了为了得到优化的效率，开发员的评审量要低于一次 200-400 行代码(LOC)。超过这个量，搜索缺陷的能力就会降低。以这个速度，您可以找到 70-90% 的缺陷。换句话说，如果存在 10 个缺陷，那么您可以找到其中的 7 到 9 个。

　　关于 Cisco 案例研究

　　在 10 个月的监视工作之后，研究总结出了一个理论：如果适当操作的话，轻量级代码评审工作与规范的评审工作同样有效，但是前者的速度会更快(更省时)。与规范评审相比，轻量级代码评审平均要少花 6.5 个小时，并发现更多的错误(bug)。

　　除了确认这些理论，研究中还发现了一些新的规律，本文将这些规律都概括了出来。

　　图 1 中的图，描述了缺陷密度与评审代码行数量之间的关系，支持该规则。缺陷密度 就是每 1000 行代码之中所发现的错误(bug)数。评审代码行的数量超过 200 时，缺陷密度就会急剧地下降。

　　在这种情况下，缺陷密度就是“评审有效性”的评价手段。如果两个评审员评审相同的代码，其中一个发现了更多的错误(bug)，那么我们就会认为该评审员更有效率。图 1 显示了当我们将更多的代码放到评审者面前时，她搜索缺陷效率的变化情况。这种结果很合理，因为她可能不会花费大量的时间去评审，这样就会不可避免的使得效率没有以前高。

　　图 1. 当代码行数量超过 200 时缺陷密度就会急剧下降，400 以后缺陷密度几乎为 0

　　回页首

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

　　定义

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

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

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

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

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

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

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

　　回页首

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

原文转自：http://www.ibm.com/developerworks/cn/rational/11-proven-practices-for-peer-review/