我们在SmartBearSoftware®的团队花了多年时间研究现有的代码审查研究，并从100多家公司的6000多名程序员那里收集了“经验教训”。 显然，人们在审阅代码时会发现错误，但是审阅通常花费太长时间才能实用。 我们使用通过多年经验收集的信息来创建轻量级代码审查的概念。 通过使用轻量级代码审查技术，开发人员可以将代码进行完整，正式代码审查所需时间的五分之一。 我们还为最佳实践开发了一种理论，该理论可用于实现最佳审查效率和价值。 本文概述了这些做法。
为了测试我们对一般代码审查和特别是轻量代码审查的结论，我们进行了有史以来规模最大的代码审查研究。 它包含2500个代码审查，50个程序员和Cisco Systems的320万行代码。 10个月的研究跟踪了MeetingPlace产品团队，该团队在班加罗尔，布达佩斯和圣何塞都有成员。
在研究开始时，我们为小组设置了以下规则：
- 在将所有代码检入团队的版本控制软件之前，必须对其进行检查。
- SmartBear的CodeCollaborator®代码审查软件工具将用于加快，组织和促进所有代码审查。
- 不允许亲自参加代码审查会议。
- 审核过程将由工具强制执行。
- 指标将由CodeCollaborator自动收集，后者提供审阅级别和摘要级别的报告。
根据我们的研究，有11种最佳做法
通常，对等代码审查（在这种情况下，软件开发人员在将软件发布给QA之前先对彼此的代码进行审查）可以识别错误，鼓励协作并保持代码的可维护性。
但是很明显，某些代码审查技术效率低下且无效。 审核过程通常要求召开会议需要花费时间并消除兴奋感。严格的过程可以扼杀生产力，但是松懈的过程意味着没人知道审核是否有效或什至正在进行。 个人批评的社会后果会破坏士气。
本文介绍了高效，轻量级对等代码审查的11个最佳实践，这些最佳实践已通过科学研究和SmartBear丰富的现场经验证明是有效的。 使用这些技术可以确保您的代码审查改进您的代码-而不浪费开发人员的时间。 并使用最新技术在IBM®Rational TeamConcert®环境中进行代码审查。
1.一次查看少于200–400行代码
思科代码审查研究（请参见侧栏）显示，为获得最佳效果，开发人员一次应审查少于200-400行代码（LOC）。 除此之外，发现缺陷的能力也会降低。 以这种速度，审阅时间不超过60-90分钟，您应该获得70-90％的收益。 换句话说，如果存在10个缺陷，您将发现其中7到9个缺陷。
图1中的图形支持缺陷密度与所检查代码行数的关系，它支持该规则。 缺陷密度是每1000行代码发现的缺陷数。 随着所审查的代码行数超过200，缺陷密度会大大下降。
在这种情况下，缺陷密度是“审查有效性”的量度。 如果两位审稿人审阅同一代码，而一位审稿人发现更多错误，我们将认为该审稿人更为有效。 图1显示了当我们在审阅者面前添加更多代码时，她发现缺陷的效率如何下降。 这个结果很有意义，因为她可能没有太多时间花在审阅上，因此，不可避免地，她不会在每个文件上都做得很好。
图1.当检查线数超过200条时，缺陷密度显着降低，而在400条之后，缺陷密度几乎为零
2.旨在使检查速度低于每小时300–500 LOC
花点时间进行代码审查。 更快不是更好。 我们的研究表明，您可以以每小时不到300–500 LOC的检查速度获得最佳结果。 留给他们自己的设备，即使使用相似的作者，审阅者，文件和审阅大小，审阅者的检查率也将有很大差异。
为了找到最佳的检查率，我们将缺陷密度与审阅者检查代码的速度进行了比较。 同样，总的结果并不令人惊讶：如果您没有在审查上花费足够的时间，您将不会发现很多缺陷。 如果审阅者不胜枚举大量代码，那么他对每行代码的关注程度可能会与他所做的很小的改动不同。 他将无法在一次会议中探讨变化的所有影响。
那么，有多快又有多快？ 图2给出了答案：每小时检查速度超过400 LOC会导致有效性严重下降。 以每小时1000 LOC以上的速度，您可能会得出结论，审阅者实际上根本没有查看代码。
图2.当审查超过500行代码时，检查有效性下降
3.花足够的时间进行适当的缓慢审查，但不要超过60-90分钟
绝不要长时间检查代码超过90分钟。
我们已经讨论了如何获得最佳结果，而不应该太快地检查代码。 但您也不应一次坐得太久。 大约60分钟后，审阅者只会感到疲倦，并停止寻找其他缺陷。 除我们自己以外，其他许多研究的证据也充分支持了这一结论。 实际上，众所周知，当人们从事任何需要集中精力的活动时，性能会在60-90分钟后开始下降。 鉴于这些人为的限制，审阅者在性能下降之前可能无法审阅300-600行以上的代码。
另一方面，即使只是一行，您也应该始终花费至少五分钟的时间来检查代码。 通常，一行可能会对整个系统产生影响，因此，花五分钟的时间来思考更改可能产生的影响是值得的。
4.确保作者在开始审阅之前注释源代码
在我们看来，作者甚至可以在开始审查之前就消除大多数缺陷。 如果我们要求开发人员仔细检查他们的工作，则可以在不影响代码质量的情况下更快地完成审阅。 据我们所知，这个特定的想法以前没有被研究过，因此我们在思科研究期间对其进行了测试。
图3.作者准备工作对缺陷密度的显着影响
作者准备的想法是作者在审阅开始之前先注释其源代码。 我们发明了这个术语来描述我们在研究过程中测得的某种行为模式，该行为模式由作者在大约15％的评论中展示。 注释指导审阅者进行更改，显示首先查看哪些文件，并为每次代码修改辩护的原因和方法。 这些注释不是代码中的注释，而是提供给其他审阅者的注释。
我们的理论是，由于作者必须重新考虑并解释注释过程中的更改，因此作者将在审查甚至开始之前就发现许多缺陷，从而使审查本身更加有效。 这样，复审过程应产生较低的缺陷密度，因为残留的错误较少。 当然，与没有作者准备的评论相比，在作者准备之前的评论几乎没有任何缺陷。
我们还考虑了悲观理论来解释较低的bug发现。 如果当作者发表评论时，审稿人有偏见或自满而又没有发现那么多错误，该怎么办？ 我们随机抽取了300条评论进行抽样调查，证据表明评论者确实在仔细地审查了代码，并且错误少了。
5.建立量化的代码审查目标，并捕获指标，以便您改善流程
与任何项目一样，请事先确定代码审查过程的目标以及如何评估其有效性。 定义了特定目标后，您将能够判断同行评审是否真正实现了所需的结果。
最好从外部指标开始，例如“将支持电话减少20％”或“将开发中注入的缺陷百分比减半”。 从外部的角度来看，这些信息可以使您清楚地了解代码的工作方式，并且需要进行量化的衡量，而不仅仅是“修复更多错误”的模糊目标。
但是，可能需要一段时间才能使外部指标显示结果。 例如，在发布新版本并交到客户手中之前，支持电话不会受到影响。 因此，观察内部流程指标以了解发现了多少缺陷，问题出在哪里以及开发人员在审查上花费了多长时间也很有意义。 用于代码审查的最常见内部指标是检查率 ， 缺陷率和缺陷密度 。
考虑到只有自动化或严格控制的流程才能为您提供可重复的指标； 人类不擅长记住停下来并开始跑秒表。 为了获得最佳结果，请使用可自动收集指标的代码查看工具，以便您对过程改进的关键指标准确无误。
要改善和完善流程，请收集指标并调整流程，以查看更改如何影响结果。 很快，您将确切地知道什么对您的团队最有效。
6.使用清单，因为它们可以显着改善作者和审稿人的结果
清单对审阅者尤其重要，因为如果作者忘记了一项任务，审阅者也有可能会错过它。
强烈建议使用清单来检查您可能忘记做的事情，这对作者和审阅者都非常有用。 遗漏是最难发现的缺陷。 毕竟，很难检查不存在的内容。 检查清单是解决问题的最佳方法，因为它会提醒审阅者或作者花时间寻找可能缺少的东西。 清单将提醒作者和审阅者确认已处理所有错误，已对函数参数进行了无效值测试，并且已创建单元测试。
另一个有用的概念是个人检查表 。 每个人通常都会犯同样的15-20个错误。 如果您发现典型的错误是什么，则可以制定自己的个人检查表（个人软件过程，软件工程学院和集成的能力成熟度模型也推荐这种做法）。 审阅者将确定您的常见错误。 您要做的只是简短列出工作中的常见缺陷，尤其是您最常忘记要做的事情。
一旦您开始在清单中记录缺陷，您就会开始减少这些错误。 这些规则将使您耳目一新，错误率也会下降。 我们已经看到这种情况一遍又一遍。
小费：
有关清单的详细信息以及清单的示例，您可以在www.CodeReviewBook.com上免费获得本文作者的《同行代码审查的最佳保留的秘密》一 书 。
7.验证缺陷是否已实际修复
好的，这种“最佳实践”似乎不费吹灰之力。 如果您要花很多精力查看代码以查找错误，则修复它们当然很有意义！ 但是，许多审查代码的团队并没有很好的方法来跟踪在审查过程中发现的缺陷，并不能确保在完成审查之前就已真正修复了错误。 在电子邮件或过时的评论中验证结果特别困难。
请记住，这些错误通常不会输入到Rational Team Concert日志中，因为它们是在将代码发布给QA之前发现的。 因此，在给代码赋予“ All Clear”符号之前，确保缺陷已解决的好方法是什么？ 我们建议使用与Rational Team Concert集成在一起的优秀协作评审软件来跟踪评审中发现的缺陷。 使用正确的工具，审阅者可以记录错误，并在必要时与作者进行讨论。 然后，作者解决问题并通知审阅者，审阅者随后必须确认每个问题都已解决。 该工具应跟踪在审阅期间发现的错误，并禁止审阅完成，直到所有错误均已由审阅者确认为已修正 （或作为单独的工作项进行跟踪，以供日后解决）。 仅当审查完成时，才应批准工作项目。
如果您要去寻找错误的麻烦，请确保已修复所有错误！
既然您已经了解了代码审查过程中的这些最佳实践，我们将讨论一些社会影响以及如何管理它们以获得最佳结果。
8.建立良好的代码审查文化，积极发现缺陷
与真正的团队建设相比，代码审查可以做的工作几乎比我们所见过的几乎任何其他技术都要多，但前提是管理人员必须通过学习，发展和沟通的手段来推动代码审查。 容易将缺陷看作是一件坏事（毕竟，它们是代码中的错误），但是对发现的缺陷持消极态度会使整个团队感到不舒服，更不用说破坏了错误查找过程。
软件代码审查的重点是消除尽可能多的缺陷，而不管是谁“引起”该错误。
管理者必须提倡缺陷是积极的观点。 毕竟，每个人都有机会改进代码，并且缺陷检查过程的目标是使代码尽可能地好。 在同行评审中发现和修复的每个缺陷都是客户从未见过的缺陷，也是质量检查人员不必花时间追踪的另一个问题。
团队需要保持一种态度，即发现缺陷意味着作者和审阅者已经成功地团队合作改进了产品。 这不是“作者创建了一个缺陷而审阅者发现了缺陷”的情况。 它更像是一种非常有效的结对编程形式。
评论为所有开发人员提供了改正不良习惯，学习新技巧并扩展其功能的机会。 开发人员可以从错误中学习，但前提是他们知道问题所在。 如果开发人员担心审核过程，那么积极的结果就会消失。
尤其是如果您是初级开发人员或刚加入团队，那么其他人发现的缺陷则表明您经验丰富的同仁在帮助您成为更好的开发人员方面做得很好。 如果没有详细的反馈，您的进度将比在真空中编程要快得多。
为了保持一致的信息，即发现错误是件好事，管理层必须保证不会在性能报告中使用缺陷密度。 公开做出这样的承诺是有效的。 然后，开发人员知道会发生什么，并可以召集任何违反如此公开制定的规则的经理。
经理也不应使用错误的代码作为负面绩效评估的基础。 他们必须谨慎行事，对伤害的感觉和对批评的负面React保持敏感，并继续提醒团队发现缺陷是好的。
9.当心大哥效应
作为开发人员，您会自动假设“老大哥在看着你”是真的，特别是如果您的评论指标是由评论支持工具自动衡量的。 您是否花了太长时间来审查某些更改？ 您的同伴在您的代码中发现太多错误了吗？ 这将如何影响您的下一次绩效评估？
度量标准绝不能用来挑出开发人员，尤其是在同行面前。 这种做法会严重损害士气。
指标对于过程测量至关重要，这反过来又为过程改进提供了基础。 但是度量可以用于善恶。 如果开发人员认为指标将被用来反对它们，那么它们不仅会对流程产生敌意，而且可能会专注于改进指标，而不是真正地编写更好的代码和提高生产力。
管理人员可以做很多事情来改善这个问题。 首先，最重要的是，他们必须意识到这一点，并继续观察以确保他们没有散布老大哥确实在仔细检查每一个举动的印象。
应使用度量标准来衡量流程的效率或流程更改的效果。 请记住，最困难的代码通常是由经验最丰富的开发人员处理的。 反过来，此代码更容易出错，因此需要进行大量检查，发现更多缺陷。 因此，大量缺陷通常更多地归因于一段代码的复杂性和风险，而不是归因于作者的能力。
如果度量标准确实可以帮助经理发现问题，那么单挑某人可能会导致超出解决方案的更多问题。 我们建议管理人员应通过整个小组来解决所有问题。 最好不要为此目的召开特别会议，因为如果看起来有问题，开发人员可能会感到不安。 相反，只需将其滚动到每周状态会议或其他正常过程中即可。
管理人员必须继续倡导发现缺陷是好的，而不是坏的，缺陷密度与开发人员的能力无关。 请记住，要确保团队清楚不应该避免缺陷，尤其是团队成员引入的缺陷数量，并且绝不能将其用于绩效评估。
10.回顾至少一部分代码，即使您不能全部完成，也要从自我效应中受益
想象一下自己正坐在编译器前，负责修复一个小错误。 但是您知道，只要您说“我完成了”，您的同事（或更糟糕的是您的老板）就会检查您的工作。 这不会改变您的开发风格吗？ 在工作时，当然在声明代码完成之前，您会更加谨慎。 您将立即成为一名更好的开发人员，因为您希望“背后的对话”的总体音色是：“他的工作很紧。他是一名优秀的开发人员；” 不是“他犯了很多愚蠢的错误。当他说完成了时，他没有。”
自我效应促使开发人员编写更好的代码，因为他们知道其他人将关注他们的代码和指标。 没有人愿意被称为犯下所有这些初级错误的人。 自我效应促使开发人员在将自己的工作传递给他人之前仔细检查自己的工作。
The Ego Effect的一个不错的特点是，无论是对所有代码更改都强制执行审核，还是将其用作“抽查”（如随机药物测试），它都同样有效。 如果您的代码有三分之一的机会被要求进行审核，那么仍然足以激励您出色地完成工作。 但是，抽查必须足够频繁以维持自我效应。 如果您只有十分之一的机会获得审核，则您可能没有那么勤奋。 您知道您总是可以说：“是的，我通常不会犯这种错误。”
查看20％到33％的代码可能会以最少的时间花费为您带来最大的自我效应收益，而查看20％的代码肯定比不查看任何代码更好。
11.采用轻量级的工具辅助代码审查
有几种主要类型，并且代码审查有无数种形式，这些准则将适用于其中的任何一种。 但是，为了完全优化您的团队在审核上花费的时间，我们通过工具辅助的轻量级审核流程获得了最佳结果。 它高效，实用且有效地发现错误。
正式检查或重量级检查已经进行了30年。 它们不再是查看代码的最有效方法。 每200行代码平均进行一次重量级检查需要9个小时。 尽管有效，但这个僵化的过程需要三到六个参与者，并且需要花费数小时的艰苦会议才能通过代码打印输出进行细致的细化。 不幸的是，大多数组织不能忍受这么长时间的束缚，并且大多数程序员鄙视所需的繁琐过程。 近年来，许多开发组织已经摆脱了会议日程安排，基于纸质的代码阅读和繁琐的度量标准的束缚，而转向新的轻量级流程，而这种新的轻量级流程避免了正式会议，并且没有较旧的笨重流程的开销。
我们使用思科的案例研究来确定轻量级技术与正式流程的比较。 结果表明，轻量级代码审查只花了正式审查时间的五分之一（或更少），但他们发现的错误也一样多。
尽管存在几种用于轻量级代码审阅的方法，例如， 按需进行审阅和通过电子邮件进行审阅，但是最有效的审阅是使用协作软件工具（例如SmartBear的CodeCollaborator ）进行的，以促进审阅（请参见图4）。
图4. CodeCollaborator，思科研究中使用的轻量级代码审查工具
CodeCollaborator是唯一与IBM®Rational Team Concert工作流集成的代码审查工具。 它将源代码查看与聊天式协作集成在一起，使开发人员摆脱了将注释与单独的代码行相关联的繁琐工作。 当程序员将变更集添加到工作项目中进行审核时，该审核将在CodeCollaborator中自动创建，并分配适当的批准者。 团队成员可以直接在代码上发表评论，与作者聊天以及彼此交流以解决问题，跟踪错误并验证修复程序。 无需会议，打印输出，秒表或时间表。
通过基于Rational Team Concert和CodeCollaborator的轻量级审查过程，您的团队可以进行更有效的审查，并充分实现代码审查的实质性好处。
因此，现在您已经拥有了一系列行之有效的实践，可以确保您从团队的角度上充分利用代码审查的时间，无论是从流程角度还是从社会角度。 当然，您实际上必须进行代码审查才能了解其好处。 正式的审核方法对于100％的代码（或某些人可能会认为的任何百分比）的实现根本是不切实际的。 集成到Rational Team Concert环境中的工具辅助的轻量级代码审查提供了最大的“实惠”，因为它提供了一种有效且有效的方法来查找缺陷，而无需开发人员讨厌执行繁琐的任务。 借助正确的工具和这些实践，您的团队可以在软件到达质量保证阶段之前，对您的所有代码进行同行审阅，并找出代价高昂的错误，从而使您的客户每次都能获得高质量的产品。
为了方便起见，以下是简单列出的11种做法，易于保存：
- 一次查看少于200–400行代码。
- 目的是使检查速度低于每小时300–500 LOC。
- 花足够的时间进行适当的缓慢审查，但不要超过60-90分钟。
- 在审阅开始之前，请确保作者对源代码进行注释。
- 为代码审查和捕获指标建立量化目标，以便您改善流程。
- 使用清单，因为它们可以显着改善作者和审稿人的结果。
- 验证缺陷是否已实际修复。
- 建立良好的代码审查文化，积极发现缺陷。
- 当心大哥效应。
- 回顾至少一部分代码，即使您不能全部完成，也要从The Ego Effect中受益。
- 采用轻量级的，工具辅助的代码审查。
CodeCollaborator已获得针对Rational Team Concert版本2和3以及针对IBM®Rational®ClearCase®和IBM®Rational®Synergy®软件的“ Ready for IBM Rational Software”验证。
翻译自: https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/index.html
725
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
