敏捷开发实战（一）：Code Review 纵览

敏捷开发实战系列

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

作者简介 

雨知

蚂蚁金服 产品专家

李素石，花名雨知，蚂蚁金服研发效能部产品专家。多年的配置管理工作，丰富的代码服务、研发模式实践经验。

01

前言

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

02

好的 Code Review 能带来什么？

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

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

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

一般来说，团队刚开始做 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. 选择合适的工具： “工欲善其事，必先利其器”。严格的流程会扼杀创造力，但是松散的流程又意味着没人知道评审是否有效，甚至是否发生。而个人批评的社会效应，又会损伤士气。业内的实践经验证明轻量级代码评审是高效的。

心态

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

蚂蚁金服代码服务平台为使用 Gitflow + 合并请求的方式进行 Code Review 的同学打造适用的CR平台，实现整体代码服务的升级，其中合并请求的操作和 Code Review 密不可分。

合并请求是代码协作的基础。 顾名思义：这是一个合并请求，从一个分支合并到另一个分支。合并请求可能是新需求、优化改造、缺陷修复等。典型的处理过程包括：如何提交合并请求？如何对合并请求进行评审以便确定是否接受？谁来处理合并？合并后的通知机制等。 通过合并请求，可以实现：

• 比较两个分支之间的变化

• 在线查看和评论代码修改，并记录问题状态

• 评审设置支持多种评审需求，如多人评审等

• 合并请求设置可以控制合并准入

• 展示合并冲突列表

• 压制合并（squash merge）让提交历史记录更清晰

• 合并请求版本，基于每次 push 产生，可以选择并比较这些合并请求差异的版本

同时，合并请求的准入设置可以有多种情况。例如，团队中的开发人员需要提交代码：

• 创建一个新的分支，并修改提交代码

• 创建合并请求提交对代码的变更

• 团队其他成员在合并请求的评审记录中进行反馈讨论

• 提交者接到邮件通知，根据评审意见修改解决

• 这些检查都通过后，批准合并

以上介绍了一些 Code Review 的实践，这些方式是否适用还需要大家在各自的实践过程中进行验证并根据实际情况进行相应的调整，以达到 Code Review 的目标。有任何疑问或者经验交流，欢迎通过公众号回复给我们，让我们一起 Code Review！

长按识别二维码关注我们

P.S.

蚂蚁金服研发效能团队招募进行中， 解决方案架构师、技术运营、数据研发专家、技术专家、技术支持专家、 产品专家、测试平台高级开发工程师、代码分析技术专家 等众多岗位持续开放，让我们共同开赴DevMind/ DevOps /DevServices三大战场，助力内部及外部伙伴研发效能的持续提升:rocket::rocket::rocket:

如果你对任何岗位感兴趣，请留下联系方式，或者发简历到： AntLinkE@antfin.com

▼  点击获取更多职位详情