研发效能领域洞察 | 敏捷开发实战（一）：Code Review 纵览-CSDN博客

敏捷开发实战系列

站在蚂蚁金服的视角，自主研发的中间件、数据库、研发平台等金融科技引领着企业数字化的技术趋势。其中，以蚂蚁研发效能为代表，催生了很多赋能行业的方法论和工程实践，基于对研发效能领域的洞察，特别推出敏捷开发实战系列文章，今天将从代码层面开始，对Code Review这个基础而重要的环节进行剖析。

01 前言

Code Review，中文称为代码评审，有时候也称为代码审查。引用维基百科的定义，Code Review 是计算机源代码的系统性检验（有时被称为同行评审）。其目的在于找到开发初期所忽略的错误，从而提高软件的整体质量。审查的形式多种多样，如结对编程，非正式走查，正式检查等。卡珀斯·琼斯（Capers Jones）分析了超过 12,000 个软件开发项目，其中使用正式代码审查的项目，潜在缺陷发现率约在 60-65% 之间，若是非正式的代码审查，潜在缺陷发现率不到 50%。大部分的测试，潜在缺陷发现率会在 30% 左右。

02 好的 Code Review 能带来什么？

发现问题：通过评审发现问题增进代码质量，这是最常见的理解，是对 Code Review 的好处的最广泛的认识。

知识共享：代码评审是一个传递知识的手段，可以让其他不熟悉代码的同学知道作者的意图和想法，尽管评审者不能像作者一样十分了解，但他会熟悉设计和架构，起到 backup 的作用。

帮助成长：代码评审是纯社会性的，也为团队提供了一个培养开发者的机会。

一般来说，团队刚开始做 Code Review 时，重点在查找问题，随着问题的逐渐减少和习惯的逐步养成，交流及知识共享会成为重点，当有大批新人加入时，查找问题将又成为重点，通过这样周而复始的过程提高代码质量，知识共享，帮助开发者成长。

03 如何做好 Code Review ？

Code Review 这项活动跟人的因素密切相关，是否有效运作跟团队状态、技术信仰和 TL 的诉求都有很大的关系。因此，在 Code Review 时，要在意识、方法、心态上培养，保持良好的 Code Review 习惯，会在各方面有很大的提升，以下将从这三方面进行展开：

意识

Code Review 的目的是提升代码质量，同时促进团队内部知识共享，帮助更多人更好地理解系统。因此，我们在意识上要明确目标和原则：

发现代码的正确性。
不仅是在 review 代码，也是在分享和学习，提升团队整体水平，提升团队维护代码的能力。
高效迅速完成 code review，不能为了应付进行。

方法

1. 明确评审内容：评审者要检查设计的合理性以及业务逻辑十分错误，检查代码的可读性：

体系结构和代码设计
代码风格

2. 提升评审质量和效率

控制每次评审的代码数量 根据 smartbear 在 Cisco 代码评审研究显示了为了得到优化的效率，开发员的评审量要低于一次 200-400 行代码（LOC）。超过这个量，搜索缺陷的能力就会降低。以这个速度，您可以找到 70-90% 的缺陷。换句话说，如果存在 10 个缺陷，那么您可以找到其中的 7 到 9 个。

随着开发平台和开发语言的不同，最优的代码审查量有所不同，但是限制每次审查的数量确实非常必要，因为这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，自然不会有太多的产出。
保障较优的评审效率 代码评审需要花费一定的时间，但快速评审并不总是好的。smartbear 在 Cisco 代码评审的研究结果显示检查率低于“300-500 LOC/小时”时，可以得到优化的结果。下图显示：服务器端每小时超过 400 LOC 的评审速度会降低效率，当评审量超过 500 行代码检查效率就会显著下降。

确认问题确实得到修复 对于评审代码发现的问题，修复它们是顺利成章的事情，我们需要有一种好的方法，来追踪评审期间发现的问题，并确保问题确实得到了修复。
多人评审 尽可能的让不同的人 review 你的代码，不同的人有不同的思考方式，有不同的见解，所以，不同的人可以全面的从各个方面评论你的代码，基本上来说，不要超过3个人，这是一个可以围在一起讨论的最大人员尺寸。

3. 总结优化：有些团队的 Code Review 活动坚持不下来或逐步流于形式，其中一个主要原因是过程中缺乏定期回顾和总结，从而不知道如何有效促进和帮助团队更好的运作。为代码评审建立可定量的目标，这样可以帮助改进流程。

4. 选择合适的工具：“工欲善其事，必先利其器”。严格的流程会扼杀创造力，但是松散的流程又意味着没人知道评审是否有效，甚至是否发生。而个人批评的社会效应，又会损伤士气。业内的实践经验证明轻量级代码评审是高效的。

心态

无论是代码作者，还是评审者，都需要一种积极向上的正面的态度，作者需要能够虚心接受别人的建议，因为别人的建议是为了让你做得更好；评审者也需要以一种积极的正面的态度向作者提意见，因为那是和你在一个战壕里的战友。团队需要维持这样一种态度，发现问题意味着代码开发者和评审者作为一个团队去改进产品的质量成功了。而不是“代码开发者产生了一个缺陷，而评审者负责去发现它”。