分为三部分内容。第一部分从方法论的角度分析业内业务代码评审的一些痛点，代码评审为什么在企业内难以推动。第二部分介绍如何根据云效codeup代码评审能力进行最终落地，称之为基于patch的评审工作流。最后介绍codeup代码评审近期能力更新以及未来规划。

 

1. 业内痛点解析一代码评审在企业内为何难以推动?

1.1 思考代码评审如何落地有以下痛点

第一是流程和工具问题，一些评审流程不清晰、过于繁琐，评审过程不透明，评审颗粒度过大，最终降低了参与意愿；

第二是时间和资源限制，在内部对于提交本身没有规范要求，如果涵盖大，没有充分内聚可能造成评审负担。另外评审发生的时间靠后，在发布之前才创建代码评审，会使评审流于形式；

第三是自动化程度不足，自动化测试和代码测试安全检测能力缺失。缺少这些数据反馈，评审参与者无法获取到足够输入，最终依靠肉眼review代码，效果难以保障。

1.2 评审核心流程

在解决痛点之前，需要清楚了解代码评审的核心流程。

核心流程包含本地编写代码，然后创建代码评审，进入迭代循环过程，包括运行自动化检查、评审者给予反馈和响应、作者进行代码优化、进一步更新代码评审。当最终效果满足后，企业可能设置一些卡点门禁条件，代码评审通过，最终完成合并。那么如何进行幸福度高的代码评审？就是要让评审的各个环节完成“小步快跑”。

下面从“小步快跑”和其他角度分析思考各个环节内如何进行代码评审实践。首先从本地编写代码角度出发，如何理解“小步快跑”。

从编码角度，小步就是做好提交。规范提交非常重要，会直接影响后续一些流程效率。一个“好”的提交从三点衡量：

第一将提交做小，“Do one thing and do it well”；

第二点做对提交，不断完善提交；

第三要做好提交，将代码本身的相关注释、文档说明以及提交说明都完善，为评审者提供一些幸福的依据，提升整个评审效率。

从快跑角度，仅将单个提交做好还不够,还要关注提交之间的逻辑化组织。一个大评审包含很多小评审。另外代码评审不能只看前后两个版本的文件差异,针对多轮评审的情况，更加要关注过程的变化、提交的变化，由远及近看每一个提交。这样可以很大程度解决重复review的问题。

1.3 小步快跑

另外可以合理使用`git range-diff`命令，可以清晰表述不同的维护版本之间提交的变动历史，缩小在循环迭代过程中需要review的范围。

再来介绍在创建代码评审的角度如何理解“小布快跑”。

1.3.1 从代码评审的角度

小步与原始化提交类似，代码评审的内容应该明确和内聚，尽量做到原子化。如何理解快跑可以分为几点思考，第一代码评审的原子化，代码评审可能有很多情况是并行处理，防止多个鸡蛋放在同一个篮子里。第二多个代码评审并行也让评审者在评审时更加聚焦，降低评审的内容复杂度。并行的评审也会给CI的流程得到提效。

还需要额外关注几点：第一创建时要跟项目管理、项目协作进行紧密的关联，例如和业务一些需求缺陷任务的观点，可以帮助评审快速的理解这些代码。代码评审有时在仓库维度在评审的描述上会有一些严格的要求，开发者要尽量的去丰富一些信息。以及希望去结合自动化流程，希望对评审本身进行打一些标记。例如设置一些里程碑，或者进行一些优先级的设置，一些类型的分类，缺陷，功能开发还是文档，方便后面进行问题的追踪。最后，很多主流大平台都是支持基于命令行的代码评审工作，可以让开发者避免在不同的工具之间进行来回切换，操作会更加便捷。

1.3.2 从自动化检查的角度

如何理解小步？

CI在本身测试运行套件时需要更新的代码不会对已有代码进行破坏。另外可以区分成宽松的CI流程和严格的CI流程。

宽松的CI流程要求评审的最新提交可以通过CI测试即可，而严格的CI流程要求评审的每一个提交都必须通过CI测试，这两种可以分为不同场景定义。

持续集成通常需要在提交后立即运行，从而提供实时反馈。对开发人员可以及时了解代码是否通过测试是否存在问题。评审者也可以根据CI情况进行特定反馈。

如何理解快跑？

开箱即用的流水线引擎和代码安全检测能力很重要，可以很快完成代码评审的集成，降低单独部署运维CI的成本。

另外Ci频繁鼓励开发者提交代码，可以解决冲突和继承问题。由于每次问题非常小而频繁，问题可以得到定位，产生冲突的概率低，解决快。

代码评审与自动化检查的结合需要在代码评审中支持检查问题之间的关联跳转，评审就可以更加快速准确的提出评审意见。

1.3.3 从评审者反馈和评审者响应两点

这两部分在代码评审的评论模块有一些使用诉求。在小步快跑一些层面分析，评审者进行反馈的每个评论都需要针对问题本身，而不是发散。此外，评审者和作者之间快速的评论回复可以确保在各自工作环境中得到及时反馈。高频的交流是大评审的优秀实践，可以有效利用工程师的碎片化时间，降低处于停滞状态。

除了小步快跑角度思考，评论的工具层面还需要具备一些关键能力，例如行内评论，提供一些具体改动的针对性的反馈。全局评论使讨论更加广泛，是整体上的问题或讨论。草稿评论可以帮助评审者有效有组织的提供反馈，给评审者预留思考与准备步骤。在评审评论的内容上，很多工具支持markdown格式，可以明显提升一些沟通的效率。另外，一些平台支持一些动态表情，可以帮助传达语气情感，增加一些功能效果。

1.3.4 循环迭代的环节

该环节面临一些痛点：

第一评审流程状态有时不明确，评审的参与者难以了解他们的责任，以及评审需要推进到的阶段；

第二评审作者一般会根据最后一次代码版本进行上一次的反馈，如果评审的更新过程不透明，很难找到当时的反馈内容，无法追溯当时的一些信息；

第三对于评审者有时面临更新的颗粒度过粗，甚至评审一旦更新，会导致评审无法从上下文中恢复，需要从头review。

解决该问题的关键是在代码评审的更新方面建设一个快照机制。快照有以下设计原则：

评审的状态机要简单清晰，并且能够支持循环迭代过程中状态的不停轮转和变化；

不论评审的周期长短，每次用户进行评审更新，代码工具本身都应该生成一个新的快照，并保证历史快照衍生的信息；

此外还需要考虑工具支持快照之间的版本对比，彻底解决更新透明、颗粒度粗以及信息无法沉淀参照的问题。

1.3.5 从卡点门禁的角度思考如何使用好卡点门禁

轻评审适用于重视迭代速度例如创业型团队或者一定阶段内业务迭代压力较大，对质量风险有一定包容度，对于这种评审，不必每次都遵循严格的卡点要求。对于重评审，适用于迭代数量稳定，代码安全质量更高要求的团队，要求除了大评审流程通过外，卡点门禁也需要符合规则。

门禁和卡点有四点考量因素：

第一从灵活性考虑，评审的卡点和门禁能力需要兼顾轻评审和重评审流程；

第二从通用性考虑，需要支持一些常见的卡点场景，例如合并情况会不会产生冲突，人员审核情况，反馈情况，根据常见的反馈情况设计卡点；

第三扩展性，体现在支持二方和三方的检查能力上，通过支持一些自定义卡点设置，满足多样化的用户诉求；

第四实时性，支持卡点配置的实时生效，在紧急发布情况下，开发在本地已经验证通过，可以快速将卡点检查的步骤自动跳过，从而尽快完成合并修复线上缺陷。

以上介绍业内痛点的解析，结合代码评审的核心流程大概介绍了如何基于小步快跑理念进行思考和分析，下面使用云效如何将上述问题进行解决和落地。

 

2. 云效落地路径——基于Patch的评审工作流介绍

2.1 从创建代码评审角度

首先从创建代码评审角度出发，进行产品演示。

查看代码评审产品的一些实现情况。

首先创建了一个分支feat/xxxxx，标题已经自动填充，标记为开发中，描述替换为详细模板可以修改其中内容。可以修改评审人，自动识别需要评审的人。通过类标可以对大评审进行打标，示例中使用的是一个markdown文件，此处改为文档和优化。

在创建完后点击确定，就可以创建出代码评审。

下一步根据自动化检查的关注点例如开箱即用、频繁提交等场景进行产品演示。演示关于codeup代码评审和自动化检查的集成能力。

进入仓库的保护分支设置，打开自动化状态检查，可以看到创建的对应流水线或者代码检测任务。在仓库配置中会自动进行检测和关联，开启代码检测任务和流水线检测，开启三个流水线（三个都需要在代码评审时运行），点击确定。

打开对应的代码评审界面，可以看到自动化检查的结果。

2.2 根据循环迭代的场景演示如何解决问题

首先重新设计了状态评审的状态机，在codeup评审中，状态简化为开发中、评审中、已合并、已关闭四个状态，在循环迭代场景中支持相互的轮转；

第二需要生成快照，保存快照衍生的其他信息。设计了一个支持基于补丁的评审更新的工作流，每次作者的代码推送都会产生一个新的patch版本，并且自动更新代码评审，在更新过程中会保留历史patch关联的所有信息，例如相关的代码改动、当时版本的评论、自动化管理的一些状态，并且这些内容可以进行随时查看和下载。基于patch的评审工作流支持快照与快照之间的版本对比，可以从patch与patch之间提交的改动维度和文件改动维度进行分别对比。在评审动态中，针对于评审更新相关的所有补丁动态都进行清晰展现。下面进行产品演示介绍patch工作流产品。

上述的代码评审创建了版本一，可以看到代码变更的初始版本和目前版本的变化，markdown的一些改动。

下面修改原分支的内容，产生新的提交，添加新的测试文件test3

点击提交后刷新页面，可以看到概览中已经新增版本二。

默认是base版本到最新版本的改动，可以在文件改动中查看变化

可以只看版本一和版本二之间的改动。除了文件改动外，可以提交改动查看提交改动视图。

默认提供了两种视图，提交列表适合初次评审时查看某个patch提交的全貌，可以通过该页面进行查看。

另外可以查看版本差异，可以查看不同版本之间的差异情况。例如作为评审者已经评审了版本一，当有新版本时只需要查看版本一到版本二提交的变化即可。

可以看到提交并没有变化，在提交上新增了一个markdown文件，通过这种方式提升评审效率，防止重新review 的尴尬发生。

在自动化检查中可以看到不同流水线当时的运行状况，帮助查看流水线问题从哪个版本引入。

另外可以下载各个版本patch 的代码下载到本地。

可以下载具体文件进行apply，可以下载特定版本，通过git命令下载到本地进行本地评审。

切换到版本一，在文件中添加一个评论：

一方面会对评论版本进行产生记录

另一方面在切换的各个位置上也会进行展示。

可以看到评论来自版本一。

上述已经介绍关于评论的关注点：行内评论、全局评论、草稿评论、markdown格式的支持、动态表情评论。

下面进行产品演示介绍评论的能力。在text3中进行一个行内评论立即发出。

在评论基础上可以进行一些回复以及提及其他人

整个回复支持markdown语法，还支持四种不同表情的回复可以帮助缓和一些回复信息的语气。

例如

这就是动态表情的回复特性。

在概览页可以筛选评论，只看某个人的评论。在筛选中可以对评论进行进一步筛选，例如待解决或者提及我。

以上就是行内评论的效果，在此基础上可以在公开页面发表全局评论。

全局评论发表后也支持筛选，当评论解决后可以标记为已解决，会自动收起，让评审者对于待解决评论更直观定位。此外对于待解决评论，支持小的效能组件设计，可以通过待解决小组件灵活切换待解决位置。

下面演示草稿评论，点击添加草稿评论。

在另外一条中也添加草稿评论

此时可以点击右上角提交草稿的能力，帮助自动袭顶，点击浏览没有问题后可以提交。

以上就是评论的整体功能。

针对卡点门禁用户需求的场景，设计了一些常见的卡点门禁帮助用户开启。下面进行产品演示。

已经配置了需要通过自动化检查的配置，作为卡点已经生效，可以配置其他卡点。

例如要求评论全部已解决，可以设置评审通过的最少人数，设置为2，进行保存。刷新页面可以看到在代码评审位置会给出相关的卡点门禁的提示，例如是否存在代码冲突、评审通过人数不足、评论未全部解决，点击可以筛选出待解决的评论，从而依次review解决、检查卡点未通过，点击可以跳转

自动定位到最新版本

以上就是目前的卡点能力。演示过后介绍开放性与体验的代码评审能力。

从openAPI以及WebHook三个方面能够支持用户轻松定制想要的评审自动化流程，可以满足不同用户场景下的不同诉求。从体验维度，支持多款创新效率组件提升评审体验。例如下载本地的动态应用，评审动态的智能筛选，评审待办的快查速切，另外还支持查看outdated评论，以及支持查看提价评论的差异等。

 

3. codeup代码评审——近期更新以及未来规划

第一首先支持了推送评审模式。推送评审模式是一款基于命令行的评审工作流的工具，用户无需安装任何工具情况下，只需执行git push原生命令就可以自动创建代码评审。

另外开发者也无需创建新的分支，不必开发完后切换到浏览器来创建评审，可以直接根据当前工作的空间版本来创建对应的代码评审。管理者可以轻松实现代码合并的强质量管控流程，例如一些管理者希望所有的变更发布代码改动都需要进行代码评审，通过推送评审模式可以很容易达成该效果。在已有的数据统计下，通过推送评审模式进行评审创建和更新的效率与原有方式相比，效率提升200倍左右。下面进行产品演示，演示命令行创建评审的流程。

上述的仓库已经下载到本地，剪出了新的分支，添加一个测试的markdown文件。

随意写一条信息，执行git push命令，会自动产生一条新的代码评审。

打开后可以看到基于命令行创建出了代码评审。

3.1 分支标签评审模式

此外重磅更新的一个模式是分支标签评审模式。

主要解决企业对于代码仓库中的分支标签的生命周期的管控流程的核心痛点。管理员可以通过开启分支标签评审模式。解决仓库久而久之出现的分支和标签管理混乱的问题。开启该模式后可能只有具备一定权限的用户才可以创建该分支。并且生命周期的管控基于代码评审流程完成，例如创建一个分支、标签都会通过代码评审的工作流程来进行管控。

下面进行产品演示，介绍分支标签评审模式的工作流程。

首先进入仓库的设置页面，选择推送规则设置，找到分支标签评审模式。

打开开关，再进行一些设置，例如命中了哪些分支标签的命名规则才可以生效，此处选择全部。选择开发者可以通过评审，评审通过的最少人数为1人，评审通过后开发者可以执行。点击保存。如果从页面新建分支输入分支名称create-branch，可以发现创建的按钮为灰色，只能通过新建评审请求的方式新建分支。创建之后无冲突，表示已有分支没有名字冲突。

评论通过人数不足，至少需要一位有权限的评审人通过，是刚才配置的卡点要求。

点击添加评审人后点击通过，此时卡点项已经进行了更新。

点击执行，评审执行成功。再查看分支，可以看到create-branch分支已经创建出。操作与命令行操作效果相同，在命令行端和页面端都适配。

3.2 支持三方自动化检查接入

介绍完近期的一些更新，再来介绍一些未来即将更新的一些特性。

首先即将更新会支持三方支持自动化检查的接入，具体支持两种接入的方式，分别是提交状态集成和检查运行集成。提交状态集成适合流程简单入门级别的devops团队，通用易上手。检查运行集成支持复杂、可能存在定制化诉求的场景，更加适合职能分工明确、对CI、CD存在较强个性化需求的团队。这两种模式用户可以分别开启使用或者相互配合。例如本地开发阶段，开发者可以通过提交状态的集成便捷查看提交的verify状态，不断修复和优化，当本地开发进入到代码评审阶段，开发者和评审者可以通过检查运行的模块提供更强的CICD的信息反馈，而无需跳转到三方的CI系统就可以具体查看到问题，并且对应一些卡点门禁，保证质量。

下图是未来的效果，在自动化检查中可能会支持两种三方检查的接入。

3.3 评审依赖

另外一个即将接入的重磅特性是评审依赖。

评审依赖支持管理MR之间的合并依赖关系，例如合并请求a依赖于合并请求b，只有在合并请求b合并后，合并请求a才能进行合并，保证了提前识别和降低，防止代码被提前或者错误合并。此外不仅支持同仓库的评审依赖，还支持不同仓库的评审依赖，构建了评审依赖的视图特性。

3.4 评审列车（评审队列）

最后即将更新的特性是评审列车（评审队列）。

借鉴了列车按时进站和离站的方式，主要目标用来有序地处理一系列代码评审任务。支持针对一次发布管理评审队列，可以通过发布队列进行把控，把控版本发布范围，防止少发或错发。通过队列机制顺序处理代码评审，可以降低代码合并时出现冲突的概率，防止冲突重复解决。评审队列可以支持集成后的代码均通过了主分支代码的测试，这有助于保证最终代码合并的质量和合并的一些问题。评审队列支持按序集成，并与主干集成，当到了最终的合并环节，队列可以自动管理合并步骤，减少手动工作和出现合并问题的概率。通过评审队列可以降低CI/CD系统面临的巨大压力，因为每个评审都需要不断提供CI。可以让CI资源得到一些释放。

以上就是分享的从方法论到落地到未来的一些规划的内容。