评审恩仇录——我为什么愿意执行代码评审

本文主要是介绍评审恩仇录——我为什么愿意执行代码评审，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

简介： 代码评审带来的好处不言自明, 但企业业务快速发展的诉求与代码评审推动落地两者之间, 往往存在矛盾。在如今快速发展的互联网时代，数字化、智能化已经是基础能力，单纯只靠人肉审查的时代已经过去了，基于各种自动化检查能力的加持，其实代码评审并没有想象中那么费时费力。今天和大家聊一聊在快节奏的业务现状下基于云效代码管理产品 Codeup 如何更低成本的开展代码评审。

难得请了年假，躺在阳光海浪仙人掌的沙滩上喝着椰汁，突然接到系统报警电话，立刻跳起来抱着电脑到处找WIFI的场景是否似曾相识。

身为技术开发，每逢放假恨不得烧香祈愿线上稳定，如果能够在问题引入前提前扼制风险，就可以放心享受悠闲的假期了。

而代码评审，就是扼制风险的有效手段之一。

代码评审带来的好处不言自明, 但企业业务快速发展的诉求与代码评审推动落地两者之间, 往往存在矛盾。在如今快速发展的互联网时代，数字化、智能化已经是基础能力，单纯只靠人肉审查的时代已经过去了，基于各种自动化检查能力的加持，其实代码评审并没有想象中那么费时费力。今天和大家聊一聊在快节奏的业务现状下基于云效代码管理产品 云效Codeup 如何更低成本的开展代码评审。

话题开始之前，先简单介绍下代码评审的概念。

代码评审，英文名是Code Review，简称CR，它是结对编程相互切磋相互学习的方式。一定频次的CR能够提升咱们的代码质量、促进人才成长。

一、提升代码质量

所谓代码质量，可以从两个维度来理解，一是可读性，二是减少缺陷。

• 可读性：Code Review 机制的诞生最早是为了保证代码具有良好的可读性。代码是一种资产，并且具有“流通性”，通常会需要多年的维护，并且面临维护人员更替的情况，谁都不希望自己接手的是一份“天书”一样的代码。使用CR的敏捷团队更是能获得巨大的好处，因为团队的工作是分散的，通过代码评审可以让团队所有人都能够有机会了解对方的代码内容，有助于促进跨库和整个团队的知识共享，让任何团队成员都可以接管并继续推进整个工程的演进。
• 减少缺陷：Code Review 能够发现除程序逻辑以外的设计、性能、安全、规范等多方面的问题。在这个过程中，除了依赖评审人的专业能力外，也给了我们更多让自动化和智能化检测手段介入的机会，包括对代码规范和安全的自动化检查、基于AI的缺陷分析和补丁推荐、合并的风险评估等。

二、促进人才成长

很多团队都由拥有不同经验的成员组成，代码评审是一个互相检查错误，互相学习代码的机会。如果团队的技术骨干人员，能参与到团队日常的架构评审、设计评审以及代码评审中，除了能够降低出错率，减少设计初期的风险故障外，还可以切切实实的帮助到其他研发人员的成长。体感更明显的团队会发现团队的开发质量在逐渐提高，并且不断在向团队最高水平成员靠拢。

三、两种评审场景

我们可以基于评审过程的严格程度，把评审分为轻/重两类，可以根据自身业务情况选择最合适的评审方式。

1.轻评审很多企业管理者会觉得评审会耽误业务的迭代速度，评审和速度是鱼与熊掌不可兼得的事，当然业务最重要，评审就被自然舍弃了。

对于看重迭代速度的企业，轻评审是一个不错的选择，它没有强制的规则卡点，不要求评审人必须严格的阅读每一行代码给出评审意见，结合自动化检测的能力，在代码合并入重要分支的时候做一次安全和质量扫描，人力投入可控，可以更加灵活的根据当前业务状况决定是否立即合并代码，可以小成本的完成评审。

2.重评审

而对于一些流程严格，或上线代码安全质量要求高的公司，从管理层就要求一系列评审的硬性卡点，包括自动化检查、必须通过的评审人数、评论解决状态等等，其中任何一条不满足都不允许合并，这种情况就需要使用重评审特性的一系列管控能力了。

还有一些企业，不仅对保护分支的合入强制管控，甚至对每一次提交都有要求，希望任何推送到服务端的代码都要经过评审，这种场景对评审的要求非常高，而Codeup创新的集中式工作流 Agit-Flow 可以很好的解决这个场景。

接下来我们先看下常规的评审流程是什么样子的：

四、常规评审流程

代码评审主要分为三个阶段：评审开始、评审中和评审结束。

常规流程中各个阶段存在的主要困难有：

• 评审开始阶段，对于发起人，需要从大量库成员中选择合适的评审人，填写必要信息完成评审创建，并通知评审人及时前来评审。而对于评审人，通常会存在多个评审邀请，需要安排工作的间隙选择适合的评审各个击破或者用固定的时段集中评审。评审人点开评审，依次浏览代码逻辑，对于比较复杂的嵌套或调用依赖，还需要去本地IDE查看内部逻辑；
• 评审过程中，负责的评审人会基于漏洞，风格，缺陷等维度提出评论。要等待评审发起人收到通知后修复代码，然后提交再次评审。如此迭代，直到问题被解决，评审人点击通过评审，如果源分支和目标分支有代码冲突的话，需要评审发起人去解决冲突，最后合并代码。

常规的代码评审流程主要有以下问题：

1.创建评审麻烦：评审的创建需要手动填写大量信息，很多操作是重复劳动或是无从下手的；

2.人力投入成本高：最传统的代码评审是结对编程，以及团队圆桌评审，人力的投入显而易见。代码评审转移到线上后，仍然需要多人仔细校对、分析和线下讨论。缺少自动化评审手段是关键。

3.评审流程体验差：评审过程中纯文本的代码难以展现代码的深刻逻辑，代码是立体的，部分改动的方法需要去查看定义和引用才能看出问题，否则只能是蜻蜓点水，效果有限，负责的评审人往往需要结合本地IDE来配合使用。评审发起人收到评论后，需要去本地修改提交后，再回复评论，路径很长。评审的通过、合并也没有卡点规则，任何有权限的人都能做这些操作，却可能会忽略评审的问题没有解决，导致本可以提前解决的问题带入线上生产环境。

4.评审活动情况难评估：管理者常常希望能够衡量，团队的成员是否真正践行评审，保证评审质量，而不是随意通过评审，只是走个流程。

五、云效智能代码评审

针对常规代码评审存在的问题，云效Codeup 通过智能算法和流程管控能力，让评审更加高效。

1.提升创建速度创建评审需要填写一堆基础信息，云效Codeup 努力将用户需要输入的内容压缩到最少：

• 增加了自动填充源、目标分支的功能；
• 支持评审人推荐，基于代码库的历史操作，将最熟悉你改动代码的库成员推荐为评审人，让你方便的选择最适合的评审者；
• 针对总是需要重复选择评审人的问题，保护分支支持设置默认评审人，减少冗余手工操作。如果你有按目录设置评审人的强大意愿，还可以使用CodeOwner模式（比如A目录让甲同学负责，B目录下的文件由乙同学负责），设置后会将对应目录的代码负责人自动加为评审人。

2.降低人力投入评审的人力投入是最大的成本，随着自动化扫描能力的增加，人工评审前的机器预评审成为了主流。

云效Codeup 提供了代码扫描能力，守护代码安全和质量。内置的代码扫描包括【代码规约扫描】、【依赖包漏洞扫描】、【敏感信息扫描】、【补丁推荐扫描】，也可以基于云效的 Flow（流水线）配置单元测试和自定义扫描节点，例如【源码漏洞检测】、PHP/Python/Go 等常见语言的代码扫描，再将结果关联到评审上。

对于比较简单的评审，自动化测试的保障已经足够，大大减少了人力和时间投入成本，同时也防控了缺陷的引入。

3.优化评审流程体验网页端对于浏览简单逻辑的代码非常方便，但是如果存在较多互相引用的函数调用，阅读起来就比较费力了。云效Codeup 针对评审复杂情况，支持了网页端的函数引用快速跳转（我们称为智能语法服务），避免在网页上艰难的切换文件视图；对于习惯本地IDE看代码的同学，云效Codeup 也支持了IDEA的代码评审插件，不用来回切换编辑器和网页，直接在IDEA里面就可以进行代码评审，甚至一键合并代码，非常方便。

另外，通常一个特性可能需要多人协作开发，为了减少合并代码时的冲突，云效Codeup 提供了冲突预检测的能力，支持通过网页端的 WebIDE 自动解决冲突并快速提交。

在评审协作通知方面，评审的关键动态支持通过站内信、邮件、钉钉的方式及时通知到评审参与方，避免你等我我等你的尴尬，能够更高效的推进评审的进度，更快一步完成迭代。

4.支持查看评审活动情况Codeup 针对评审活动，提供了单独的度量报表，可以看到仓库内每次提交是否经过了评审，查看提交和代码行的评审率，每个仓库成员的评审活动参与次数，收到评审邀约的响应速度，如果有同学评审总是拖延，可能他就是迭代的一个阻塞点，也许应该为他减轻工作或者选择其他评审人帮助补位；

在评审活动中，我们也是鼓励评论的，有问题说出来，无论是疑问还是夸赞，也方便后续的回顾追溯。此外，千行代码评论数也可以作为管理者对评审有效性评估的可视化度量参考。

作者：Yvonne
原文链接
本文为阿里云原创内容，未经允许不得转载

这篇关于评审恩仇录——我为什么愿意执行代码评审的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！