成功的同行评审策略要求严格记录的流程与非威胁性、协作性环境之间保持平衡。高度规范的同行评审可能会抑制生产力，然而，过于随意的流程往往效果不佳。经理们需要找到一种折中方案，使同行评审既高效又有效，同时促进团队成员之间的开放交流和知识共享。
10 条指导你进行同行代码有效评审的建议
1、每次审查的代码行数不超过 400 行
SmartBear对思科系统编程团队的研究表明，开发人员一次应该审查不超过200到400行的代码（LOC）。大脑一次只能有效地处理这么多信息；超过400LOC，发现缺陷的能力就会减弱。
在实际操作中，60到90分钟内对200-400LOC的审查应该能够发现70-90%的缺陷。因此，如果代码中存在10个缺陷，正确进行的审查将发现其中7到9个。
2、慢慢来。检查速度应该低于每小时500行代码（LOC）
在合理数量下，以较慢的速度，在有限的时间内进行代码审查，会获得最有效的代码审查结果。
3、一次 Code Review 不要超过60分钟
正如你不应该过快地审查代码一样，你也不应该一次性审查过长时间。当人们从事任何需要集中一段时间精力的活动时，在大约60分钟后性能开始下降。研究表明，在一段时间内从任务中休息可以大大提高工作质量。进行更频繁的评审应该减少需要进行如此长时间评审的需求。
4、设定目标并获取指标
在实施流程之前，您的团队应决定如何衡量同行评审的有效性，并列出一些具体的目标。
使用SMART标准，首先从外部指标开始。例如，“将支持电话减少15％”或“将开发引入的缺陷百分比减半”。这些信息应该为您提供了您的代码如何改进的量化图像。“修复更多错误”不是有效的目标。
监视内部流程指标也很有用，包括：
- 检查率：进行审查的速度
- 缺陷率：每小时审查中发现的错误数量
- 缺陷密度：每行代码平均发现的错误数量
实际上，只有自动化或严格控制的流程才能提供可重复的指标。以指标为驱动的代码评审工具可以自动收集数据，从而确保您的信息准确且不受人为偏见的影响。为了更好地了解有效的代码评审报告，您可以看看我们的代码评审工具Collaborator是如何做的。
5、作者应在审核前对源代码进行注释
在审核前，作者应对代码进行注释，因为注释会引导审核员查看更改内容，指出应先查看哪些文件，并解释每次代码修改的原因。注释应针对其他审核员，以简化过程并提供更多上下文信息。此外，作者通常会在同行评审开始前发现更多错误。在同行评审之前发现更多错误将降低缺陷密度，因为总体上存在的错误较少。
6、使用检查清单
团队中的每个成员很可能反复犯同样的 10 个错误。特别是遗漏是最难发现的缺陷，因为很难审查不存在的东西。检查表是消除经常出现的错误以及应对遗漏发现挑战的最有效方法。代码审查检查表还为团队成员提供了每种审查的明确期望，并有助于跟踪报告和改进流程的目的。
7、建立缺陷修复流程
即使通过限制审查时间、每小时审查的代码行数以及为团队命名关键指标来优化代码审查流程，仍然缺少一个关键的审查步骤。这些错误该如何修复？这似乎是显而易见的，但许多团队却没有系统的方法来修复他们千辛万苦找到的bug。
确保缺陷得到修复的最佳方法是使用协作式代码审查工具，让审查者能够记录bug，与作者讨论，并批准代码中的更改。如果没有自动化工具，审查中发现的bug可能不会被记录在团队的常规缺陷跟踪系统中，因为它们在代码发布到QA之前就被发现了。
8、培养积极的代码评审文化
同行评审会对团队人际关系造成压力。让同事评审你的每一行代码，以及让管理人员评估和测量你代码中的缺陷密度，都是一件困难的事情。因此，为了同行代码评审的成功，管理人员必须创建一种协作和学习的文化，这一点极其重要。
虽然很容易将缺陷视为纯粹的负面因素，但每个缺陷实际上是团队提高代码质量的一次机会。同行评审还允许初级团队成员从高级领导那里学习，甚至是最有经验的程序员也能改掉坏习惯。
在同行评审中发现的缺陷不能作为评估团队成员的一个可接受标准。从同行代码评审中拉出的报告绝不应用于绩效评估报告。如果个人指标成为补偿或晋升的基础，开发人员将对这一过程产生敌意，并自然而然地关注提高个人指标，而不是编写更好的整体代码。
9、接受同行评审的潜意识影响
知道别人会检查自己的代码，自然会促使人们创造更好的代码。这种“自我意识效应”自然激励开发者编写更干净的代码，因为他们的同事肯定会看到。SmartBear 对思科系统的研究表明，抽查20%至33%的代码，就能以最少的时间投入降低缺陷密度。如果你的代码有1/3的机会被叫出来审核，那就有足够的动力去复查你的工作了。
10、轻量级代码审查实践
电子邮件、肩并肩、微软Word、工具辅助以及所有类型的混合协作代码评审方法不胜枚举。但是，为了充分优化团队的时间并有效衡量其成果，建议采用轻量级、工具辅助的流程。
SmartBear对思科系统的研究发现，轻量级代码评审所需时间不到正式评审的20%，而发现的错误数量则一样多！正式或重量级的检查平均需要每200 LOC（Lines of Code，代码行数）9小时。虽然这种方法通常有效，但这种僵硬的过程需要多达6名参与者，并且需要数小时的时间来浏览详细的代码打印输出。
