《11个高效的同行代码评审最佳实践》由会员分享，可在线阅读，更多相关《11个高效的同行代码评审最佳实践（15页珍藏版）》请在金锄头文库上搜索。
1、11个高效的同行代码评审最佳实践作者: Jason Cohen 来源: IBM 发布时间: 2012-08-11 13:40 阅读: 549 次 原文链接 全屏阅读 收藏 摘要：这 11 项针对轻量级高效同行代码评审最佳实践被证明是有效的，它们建立在一个通过结合使用 IBM Rational Team Concert 与 SmartBear CodeCollaborator 对 Cisco 系统的开发进行案例研究的基础之上。它们可以帮助您确保评审既能够改进您的代码，又能利用好开发人员的时间。英文原文：11 proven practices for more effective, efficie
2、nt peer code reviewSmartBear Software 团队 花费了数年时间去搜索已有的代码评审研究成果，并从超过 100 家公司的 6000 多名程序员那里，收集了“实践经验”。很显然，人们在评审代码时会发现一些错误（bug），但是这种评审工作通常会花费大量的时间，因此变得不太实际。我们通过数十年的经验使用获得的信息，来创建轻量级代码评审的概念。通过使用轻量级代码评审技术，开发员只需要花费五分之一的时间就可以进行全面且规范的代码评审工作了。我们还开发了最佳实践的理论，以便部署实现评审的效率与价值。本文概括了以下的这些实践。为了测试我们对代码评审及轻量级评审的结论，我们对代
3、码评审进行了最大规模的研究工作。它涉及包含了 2500 个代码评审案例，50 个程序员，及 Cisco 系统上 320 万行的代码。在 10 个月的时间内，研究追踪了 MeetingPlace 产品团队，该团队拥有 Bangalore，Budapest 及 San Jos 方面的成员。在研究开始时，我们要为这个团队创建以下的规则： 在签入到团队的版本控制软件之前，所有的代码都必须进行评审。 SmartBear 的 CodeCollaborator 代码评审软件工具，应该用于精化，组织和改进所有的代码评审工作。 代码评审的全体会议是不允许的。 评审过程会得到工具的支持。 CodeCollabor
4、ator 会自动收集工具，提供评审层次和总结层次的报告。根据我们的研究结果，总结了 11 项最佳实践您应该警惕，平等代码评审（在该过程中，软件发布以确保质量之前，软件开发员会相互评审代码）会识别代码中存在的错误（bug），鼓励协作，并使代码变得更有维护性。但是很明显的一点是，有些代码评审技术是低效低能的。评审过程中的一些会议会占用时间，并抑制活力。严格的流程会扼杀创造力，但是松散的流程又意味着没人知道评审是否有效，甚至是否发生。而个人批评的社会效应，又会损伤士气。本文描述了考虑效率时的 11 项最佳实践，科学研究和 SmartBear 领域内的经验证明轻量级同行评审是高效的。使用这些技术，可以
5、确保代码评审能够改进代码 而不用占用开发员的时间。您可以使用最新的技术，在 IBM Rational Team Concert 环境之中评审代码。1. 一次评审量要低于 200400 行代码关于 Cisco 案例研究在 10 个月的监视工作之后，研究总结出了一个理论：如果适当操作的话，轻量级代码评审工作与规范的评审工作同样有效，但是前者的速度会更快（更省时）。与规范评审相比，轻量级代码评审平均要少花 6.5 个小时，并发现更多的错误（bug）。除了确认这些理论，研究中还发现了一些新的规律，本文将这些规律都概括了出来。Cisco 代码评审研究显示了为了得到优化的效率，开发人员的评审量要低于一次
6、200-400 行代码（LOC）。超过这个量，搜索缺陷的能力就会降低。以这个速度，您可以找到 70-90% 的缺陷。换句话说，如果存在 10 个缺陷，那么您可以找到其中的 7 到 9 个。图 1. 当代码行数量超过 200 时缺陷密度就会急剧下降，400 以后缺陷密度几乎为 0图 1 中的图，描述了缺陷密度与评审代码行数量之间的关系，支持该规则。缺陷密度就是每 1000 行代码之中所发现的错误（bug）数。评审代码行的数量超过 200 时，缺陷密度就会急剧地下降。在这种情况下，缺陷密度就是“评审有效性”的评价手段。如果两个评审员评审相同的代码，其中一个发现了更多的错误（bug），那么我们就会认
7、为该评审员更有效率。图 1 显示了当我们将更多的代码放到评审者面前时，她搜索缺陷效率的变化情况。这种结果很合理，因为她可能不会花费大量的时间去评审，这样就会不可避免的使得效率没有以前高。2. 每小时低于 300500 LOC 检查率的目标定义 检查率： 我们能够多快地评审代码呢？通常以每小时 kLOC（千代码行）来评价。 缺陷率： 我们能够多快地发现缺陷呢？通常以每小时缺陷数来评价。 缺陷密度： 给定量的代码之中我们能够发现多少的缺陷呢（而不是它们有多少）？通常以每 kLOC 中发现的缺陷数来评价。您要花点时间进行代码评审。快速评审并不总是好的。我们的研究结果显示检查率低于“300-500 L
8、OC/小时”时，可以得到优化的结果。根据所作的决定，评审者的检查率有很大的变化，就算是相似的代码开发者、评审者，文件和评审规模，也存在巨大的差异。为了找到优化的检查率，我们将缺陷密度与评审者检查代码的速度进行了比较。得到的结果再一次落在了我们的预料之中：如果在评审时您不花足够的时间，那么您就不会发现太多的缺陷。如果评审者面临大量代码的压力，那么他就不会每一行代码投入相同的注意力。他不能研究同一位置处更改的所有版本。所以，多快算是太快呢？图 2 显示了答案：服务器端每小时超过 400 LOC 的评审速度会降低效率。而每小时 1000 LOC 的速度，您可能已经退出了，以这样的速度评审员可能根本都
9、没有细看代码。图 2. 评审量超过 500 行代码时检查效率就会下降了3. 花足够的时间进行适当缓慢的评审，但是不要超过 60-90 分钟永远不要对一个原型代码评审超过 60-90 分钟我们应该讨论，为了得到更好的结果，不应该过快地评价。但是您也不应该在一个位置花太多的时间。大约 60 分钟后，评审者就会感到疲劳，于是就不会找到额外的缺陷了。这个结论得到了许多其他研究的支持。实际上，根据我们的常识，当人们从事注意力高度集中的活动时，性能状态在 60-90 分钟之后就会降低了。考虑到人体方面的限制，评审者在性能降低之前，不能评审超过 300600 行的代码。但反过来说，评审代码所花的时间不得低于
10、五分钟，就算代码只有一行也是如此。通常来说，单行的代码也会影响到整个的系统，所以花上五分钟时间去检查更改可能造成的结果是值得的。4. 确定在评审开始之前代码开发者已经注释源代码了在评审开始之前代码开发者可能就消除大多数的缺陷，这一点我们将会看到。如果我们需要开发人员双倍地检查他们的工作，那么评审可能更快地完成，而不用再去折中考虑代码质量的问题。就我们所知，这种特定的想法尚未得到研究，所以我们在 Cisco 研究期间对其进行了测试。图 3. “代码开发者准备”对缺陷密度的震撼性效果“代码开发者准备”说的是代码开发者在评审之前要先注释他们的源代码。我们发明了这个术语，以描述研究中所评价的特定行为模
11、式，大约 15% 的评审会阻止代码开发者这样做。注释会指导评审者进行变更，显示首先必须要查看的文件，并找到每一次代码更改的原因。这些注释不是代码之中的评论，而只是给其他评审者看的评论。我们的理论就是，因为代码开发者需要重新考虑，并解释注释过程中所发生的更改，所以代码开发者需要在评审开始之前就找出许多缺陷，以让评审变得更加有效。如此，评审过程将会产生低密度的缺陷，因为更少的错误（bug）剩余了。很明显，与没有代码开发者准备的评审相比，代码开发者准备之后的评审有更少的缺陷存在。我们还考虑过一个悲观的理论，以解释错误（bug）的低发现率。是不是当代码开发者在作出一项评论时，评审者会有偏见，或者自鸣得
12、意，这样就不能尽可能多地发现错误（bug）了呢？我们随机抽查了 300 个评审者进行研究，结果证实评审者在评审代码时确实非常小心，更少的错误（bug）被发现了。5. 为代码评审创建可定量化的目标，并获取制度，这样您就可以改进流程了有了项目，您就该决定代码评审过程的目标，以及怎样评价效率问题了。当您在定义特定的目标时，您就能够决定同行评审是否真的达到了您所需要的结果。最好从外部性的制度开始，例如“将支持访问降低 20%”或者“使开发引入的缺陷百分比减半”。这些信息使您能够更好地看清，从外部视角来看，代码能够做些什么，您还需要一个可定量化的评价手段，而不是“修复更多错误（bug）”的模糊目标。但是
13、，在外部制度显示结果之前需要花上一段时间。例如，支持性访问将不会得到影响，直到新的版本得到发布并交到客户手中为止。所以查看内部性流程工具，以得到发现多少缺陷，缺陷就是问题所在，以及开发人员在评审上所花时间的清晰结果。代码评审的最常见内部性制度是检查率 ，缺陷率，以及缺陷密度。考虑一下只有自动化或者紧密控制的流程，才能给您带来可重复的代码；人类并不擅长记住启动或者终止计时器。为了得到最好的结果，您要使用能够自动收集代码的代码评审工具，这样用于流程改进的关键代码就是精确的了。为了改进和提高您的流程，您可以收集代码并组合流程，以查看更改是如何影响结果的。很快，您就将会知道什么工作最适合您的团队了。6
14、. 使用检查表，因为它能极大地影响代码开发者和评审者的结果使用检测表对于评审员非常重要，如果代码开发者忘记了某项任务，评审员也同样可能忘记。我们极力推荐您使用检查表，来确定您可能会忘记的事情，它对代码开发者和评审者都有用。忽略是最难发现的缺陷；毕竟，评审不在那里的东西是很困难的一件事。检查表是解决这个问题的最好方式，因为它会提醒评审者和代码开发者花点时间去考虑一下可能被遗忘的事情。检查表还会提醒代码开发者和评审者确定所有的错误（bug）都得到了处理，软件功能已经通过了无效值测验，而且已经创建了单元测试。另外一个有用的概念就是个人检查表 。每个人一般都会犯 15-20 个错误（bug）。如果您注
15、意到了一些典型的错误（bug），那么您就可以开发自己的个人检查表（Personal Software Process，Software Engineering Institute，以及 Capability Maturity Model Integrated 也都推荐该实践方式）。评审者将会完成决定一般性错误（bug）的工作。您所应该做的，就是拥有一个简短的检查列表，一般都是您容易遗忘的事情。一旦您开始在检查列表中记录自己的缺陷，那么您就会少犯错了。规则将不断出现在您的脑海中，然后您的错误（bug）率就会下降了。这种情况我们将会发现它反复出现。提示：如果您想要得到关于检查列表的更多具体信息，那么您可以得到本文代码开发者所写书籍的免费拷贝，这本书为 Best Kept Secrets of Peer Code Review，网址为 www.CodeReviewB。7. 确认缺陷得到了修复是的，这种“最佳实践”看起来好像是没有脑子的。如果您遇到了评审代码以找到缺陷的所有问题，那么修复它们就变得顺理成章了！现在许多评审代码的团队没有一种好的办法，去追踪评审期间找到的缺陷，并确保评审完成之前错误（bug）确实得到了修复。确认电子邮件之中的结果，或者实时评审是非常困难的。记住这些错误（bug）通常不是在 Ration
