编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。

代码评审，英文名是 Code Review，简称 CR，它是结对编程相互切磋相互学习的方式。严肃地讲，CR能够提升代码质量、促进人才成长、培养技术情怀。

首先，代码也是一种资产且具有“流通性”，通常会需要 3 到 5 年的维护。过程中将面临维护人员更替、其他人参考引用的情况，谁都不希望自己接手或参考的是一份“天书”一样的代码。所以通过 CodeReview能够发现除程序逻辑以外的设计、性能、安全、规范等多方面的问题。

其次，CodeReview 是一个互相检查错误，互相学习代码用法的机会。如果团队的核心骨干人员，能参与到团队日常的架构评审、设计评审以及代码评审中，一定可以切切实实地帮助到其他研发人员的成长，不论是新人的融入，还是处于瓶颈期的其他研发人员。我们期望看到 CodeReview 可以促使团队"战斗力"的提升。同时CodeReview 因为涉及到研发之间就某一个具体的问题或场景交互式的讨论，所以也成为了工程师们提升编程能力的最佳途径。

最后，CodeReview 是一种文化，通过一个个小团队内部的评审实践逐渐形成为 IT 企业的一种开发者文化。当一个企业拥有了特定的技术文化，这对人才的吸引和成长是至关重要的。

传统评审流程的问题

如上图所示，代码评审主要分为三个阶段：评审开始、评审中、评审结束。

1. 评审开始阶段，发起人需要从大量库成员中选择最熟悉改动代码的若干人作为评审人，选择开发分支和目标分支，填写评审描述信息，建成评审，评审通知会发送给受邀的评审人。一个评审人通常会收到多个评审邀请，他需要安排工作的间隙选择适合的评审各个击破或者用固定的时段集中评审。评审人点开评审，依次浏览代码逻辑，对于比较复杂的嵌套或调用依赖，需要去本地 IDE 查看内部逻辑和影响范围。
2. 评审过程中，负责的评审人会基于漏洞异常，代码风格，性能缺陷，重复代码等维度提出评论。评审发起人收到评论通知后，会重新审视问题代码，修改或重构局部问题行，再次提交并更新评审。如此迭代，直到问题被解决。
3. 评审结束后，评审人点击通过评审，如果源分支和目标分支有代码冲突的话，需要评审发起人去解决冲突，最后合并代码。

综上所述，传统的代码评审流程主要有以下几个问题：

1. 创建速度慢，评审的创建需要手动填写大量信息：选择分支，填写描述，选择评审人，关联工作项等。
2. 人力投入大，最传统的代码评审是结对编程，以及团队圆桌评审，人力的投入显而易见。
3. 评审内容杂，不规范的评审会存在变更文件过多，变更版本错乱，多个需求混合等现象，导致评审的代码难以理解，评审过程无从下手，文件间逻辑难以关联，文件跨度过长忘记前文逻辑等问题。
4. 效果评估难，作为管理者常常在评审问题上犯难，他们认为评审是一个重要且正向的流程，促进代码质量和团队协作。但是团队的成员是否能真正践行评审保证评审质量，而不是随意通过走个流程，是管理者困惑且急需知道的。同时管理者也想知道评审流程的投入是否能带来足够的回报。

智能代码评审

针对传统评审流程面临的问题，阿里巴巴的代码平台团队借助智能化和流程管控的手段，提升评审效率，如下图所示：

具体从以下几个方面进行优化：

1. 通过对代码库维度的评审数据进行智能分析，自动完成创建评审过程中的信息填充从而提升评审创建的效率，同时还提供以客户端命令行的方式快速创建评审。
2. 通过丰富的代码自动化检测工具链，尽可能减少人工 review 的内容。例如通过阿里巴巴 Java 规约检测工具自动发现不符合代码规范的代码并给出修复建议。
3. 通过大评审拆分，针对包含文件数过多的评审按文件相关度进行智能拆分，将一个超大的评审拆分成若干个小评审，并根据评审的内容和当前评审人的工作饱和度智能选择合适的评审人进行评审。这样通过精简评审内容来提高评审的有效性，避免走马观花的形式评审。
4. 评审虽然依靠人工，但整个流程是数字化的，提供了丰富的代码报表数据，帮助管理者更好的管理和优化评审流程，指导管理者对评审带来的效果进行有效的评估。

评审人推荐

通过智能算法，自动推荐最合适的评审人。对于大型应用，和跨团队共建的中台应用，自动推荐可以节约大量的沟通成本，快速推进评审流程。

评审耗时预估

通过提交数据分析当前一次评审预计需要多长时间可以完成，帮助评审人根据当前评审所需的时间来合理安排自己的工作。此外，对于一个评审人同时拥有多个代码评审的场景，还可以根据评审耗时来安排评审任务的优先级。

git-repo 评审工具

git-repo 是由阿里巴巴开发的一款客户端工具，可以从客户端直接发起代码评审，实现在客户端快速创建并在页面端快速打开浏览。git-repo 并不会改变 git 用户的使用习惯，而是提供了对 git 命令的扩展。

传统的代码评审工作模式，代码贡献者要将代码推送到个人/特性分支，再通过在浏览器页面上发起创建合并请求，整个过程要经历多个步骤，开发者要切换到不同的工具才能完成。而使用 git-repo，一个用户只要拥有仓库的读取权限，就可以在本地工作区中执行下面的一条命令，将代码以合并请求的方式贡献到服务端。

总结

在阿里巴巴内部，从上自下都在推行代码评审文化，要求每个开发者不仅要对自己的代码负责，也要作为代码评审人帮助其他同事一起把控代码的发布质量。想要做好一个评审，除了需要好用的工具辅助之外，还需要开发者注意以下几点：

• 做好提交，即将提交做小做好。写小提交就是将问题解耦：“Do one thing and do it well”。每个提交控制在只修改一个到几个文件，每次只修改几行到几十行。每个提交应该是一个完整的功能，可能是修改某个bug 或完成某个小需求的开发。
• 充分描述，对于代码评审描述应介绍本次改动的需求背景，改动范围及影响点。一段清晰的评审描述能让reviewer充分理解需求背景，快速开始评审，降低沟通成本。
• 数字化度量，通过数据洞察获得团队质量情况，有策略的提升团队技术能力。

免费下载《阿里巴巴DevOps实践指南》

阿里巴巴合伙人和业界多位大佬力荐、何勉、陈鑫等17位阿里资深技术专家联袂出品、阿里十年DevOps经验沉淀总结、阿里巴巴DevOps落地实践一本通。

前往：https://developer.aliyun.com/topic/devops，下载完整版电子书。