房地产网站建设公司

简介：这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. 一次评审量要低于 200400 行代码

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. 每小时低于 300500 LOC 检查率的目标

定义

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

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

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

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

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

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

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

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

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

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

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