简介：这 11 项针对轻量级高效同行代码评审佳实践被证明是有效的，它们建立在一个通过结合使用 IBM？ Rational Team Concert？ 与 SmartBear CodeCollaborator 对 Cisco 系统的开发进行案例研究的基础之上。它们可以帮助您确保评审既能够改进您的代码，又能利用好开发人员的时间。

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

　　为了测试我们对代码评审及轻量级评审的结论，我们对代码评审进行了大规模的研究工作。它涉及包含了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