11项针对轻量级高效同行代码评审-1
上一篇 / 下一篇 2012-08-23 09:37:37 / 个人分类：杂谈
简介：这 11 项针对轻量级高效同行代码评审最佳实践被证明是有效的，它们建立在一个通过结合使用IBM？RationalTeam 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
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% 的评审会阻止代码开发者这样做。注释会指导评审者进行变更，显示首先必须要查看的文件，并找到每一次代码更改的原因。这些注释不是代码之中的评论，而只是 给其他评审者看的评论。
我们的理论就是，因为代码开发者需要重新考虑，并解释注释过程中所发生的更改，所以代码开发者需要在评审开始之前就找出许多缺陷，以让评审变得 更加有效。如此，评审过程将会产生低密度的缺陷，因为更少的错误（bug）剩余了。很明显，与没有代码开发者准备的评审相比，代码开发者准备之后的评审有 更少的缺陷存在。
我们还考虑过一个悲观的理论，以解释错误（bug）的低发现率。是不是当代码开发者在作出一项评论时，评审者会有偏见，或者自鸣得意，这样就不 能尽可能多地发现错误（bug）了呢？我们随机抽查了 300 个评审者进行研究，结果证实评审者在评审代码时确实非常小心，更少的错误（bug）被发现了。
5、为代码评审创建可定量化的目标，并获取制度，这样您就可以改进流程了
有了项目，您就该决定代码评审过程的目标，以及怎样评价效率问题了。当您在定义特定的目标时，您就能够决定同行评审是否真的达到了您所需要的结果。
最好从外部性的制度开始，例如“将支持访问降低 20%”或者“使开发引入的缺陷百分比减半”。这些信息使您能够更好地看清，从外部视角来看，代码能够做些什么，您还需要一个可定量化的评价手段，而不是“修复更多错误（bug）”的模糊目标。
但是，在外部制度显示结果之前需要花上一段时间。例如，支持性访问将不会得到影响，直到新的版本得到发布并交到客户手中为止。所以查看内部性流 程工具，以得到发现多少缺陷，缺陷就是问题所在，以及开发员在评审上所花时间的清晰结果。代码评审的最常见内部性制度是 检查率 ，缺陷率，以及 缺陷密度。
考虑一下只有自动化或者紧密控制的流程，才能给您带来可重复的代码；人类并不擅长记住启动或者终止计时器。为了得到最好的结果，您要使用能够 自动 收集代码的代码评审工具，这样用于流程改进的关键代码就是精确的了。
为了改进和提高您的流程，您可以收集代码并组合流程，以查看更改是如何影响结果的。很快，您就将会知道什么工作最适合您的团队了。
6、使用检查表，因为它能极大地影响代码开发者和评审者的结果
使用检测表对于评审员非常重要，如果代码开发者忘记了某项任务，评审员也同样可能忘记。
我们极力推荐您使用检查表，来确定您可能会忘记的事情，它对代码开发者和评审者都有用。忽略是最难发现的缺陷；毕竟，评审不在那里的东西是很困 难的一件事。检查表是解决这个问题的最好方式，因为它会提醒评审者和代码开发者花点时间去考虑一下可能被遗忘的事情。检查表还会提醒代码开发者和评审者确 定所有的错误（bug）都得到了处理，软件功能已经通过了无效值测验，而且已经创建了单元测试。
另外一个有用的概念就是 个人检查表 。每个人一般都会犯 15-20 个错误（bug）。如果您注意到了一些典型的错误（bug），那么您就可以开发自己的个人检查表（Personal Software Process，Software Engineering Institute，以及 Capability Maturity Model Integrated 也都推荐该实践方式）。评审者将会完成决定一般性错误（bug）的工作。您所应该做的，就是拥有一个简短的检查列表，一般都是您容易遗忘的事情。
一旦您开始在检查列表中记录自己的缺陷，那么您就会少犯错了。规则将不断出现在您的脑海中，然后您的错误（bug）率就会下降了。这种情况我们将会发现它反复出现。
7、确认缺陷得到了修复
是的，这种“最佳实践”看起来好像是没有脑子的。如果您遇到了评审代码以找到缺陷的所有问题，那么修复它们就变得顺理成章了！现在许多评审代码 的团队没有一种好的办法，去追踪评审期间找到的缺陷，并确保评审完成之前错误（bug）确实得到了修复。确认电子邮件之中的结果，或者实时评审是非常困难 的。
记住这些错误（bug）通常不是在 Rational Team Concert 日志中输入的，因为在代码发布给 QA 之前就发现了这些错误（bug）。所以，什么是代码在贴上“全部解决”标志之前确认缺陷的好办法呢？我们建议使用好的协作性评审软件，与 Rational Team Concert 相集成，以追踪评审之中所发现的缺陷。有了正确的工具，评审员就可以记录错误（bug），并在必要时与代码开发者进行讨论了。然后代码开发者会修复问题， 并通知评审者，而评审者必须确认每个问题都得到了解决。工具应该追踪评审期间所发现的问题，并确保直到所有的错误（bug）被评审者 修复 才完成评审（或者作为稍后解决的单独工作项追踪）。工作项只有在评审完成时才能通过。
如果您真面临着搜索错误（bug）的烦恼，那么请确认您已经将它们全部安装了！
既然您已经学会了代码评审 流程 的最佳实践方式，那么我们接下来将会讨论一些社会效应，以及怎样管理它们以获得最佳的结果。
8、培养良好的代码评审文化氛围，在这样的氛围中可以积极地评审缺陷
与其他我们能看到的大多数技术相比，代码评审对于真实团队构建能够发挥更大的作用，但是只是在管理人员能够以一种积极的，向上的，有技巧的方式 进行交流时，这种优势才能发挥出来。将缺陷看做是不好的事物很容易（毕竟，它们是代码之中的错误（bug）），但是形成不好的缺陷检查态度，则会毁掉整个 团队的努力，更不要说它会破坏错误（bug）检查过程了。
软件代码评审的要点在于，尽可能多的消除缺陷，不管是谁“导致”了错误（bug）。
管理人员必须建立缺陷是积极的这样的观点。毕竟，每一个缺陷的存在，都是改进代码的潜在机会，而错误（bug）评审过程的目的，就在于使代码尽可能地完美。每一个被发现并解决的缺陷，都是客户以后不会看到的缺陷，也是 QA 人员不必花费时间去解决的问题。
TAG:
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | |||||||
我的存档
数据统计
- 访问量: 3338600
- 日志数: 1640
- 建立时间: 2011-12-07
- 更新时间: 2019-12-24
