我对代码评审效率提升措施的思考

下面是某个实施「提交即CR」的团队成员对于 CR 工具与文化的思考。其中，强调了工具的优化点，以便正向促进 CR 质量与效率。

正文如下：

在不降低CR质量的前提下加速代码评审的完成时间，达到99%在半天内完成的目标。

由于变更复杂性和代码质量的不平衡性，代码评审过程可能会有多次往复，只考察代码评审的反应时间，不考虑从发起到最终提交的时间。

目前我们的代码评审基于GIT和CR平台，分析存在如下问题：

2.1 修改不科学

混合不同目的的修改，导致增加评审难度、注释不清使得评委难以理解代码。

代码修改经常可以分2种情况：

（1）微小变更

• 格式/代码规范方面的修改

• 低级错误修复

• 修复UT错误

（2）较大变更

• 特性实现

• 代码重构

微小变更通常很少有问题，基本不涉及评论，应该能够快速通过，发起评审的目的主要是备案和知会相关人员。

较大变更则需要评审人仔细地去阅读代码，需要花费较多的时间和精力，评审本身难以优化，只能从代码质量，催办机制，待评审列表优化等方面着手。

至于一次发起太大的变更，这种行为应该禁止。

因此优化的一个关键着手点是识别出微小变更，更加智能高效地推送给评委去快速评审。

2.2 代码问题较多造成评审往复

特别是对新手，容易出现代码质量不够高，也存在评委评论表达不够清晰的情况。

2.3 通知机制不科学

CR平台针对每次变更推送大量单条通知，甚至每条评论一次通知，反而淹没了真正有意义的通知。另外还存在一些完全无意义的通知（比如代码已提交成功，都提交了还通知干嘛）。

另外对于积压的评审也缺少催办机制。

2.4 待办列表不科学

没有按优先级排列。

夹杂着无意义的事项，比如已经评审完驳回但是还没更新的，已经关闭的，已经提交的等。

2.5 评审不方便

只能在Web页面上评审，这时如果评委不在电脑前就比较麻烦。

3.1 代码作者侧

（1）要求对变更分类，每次变更只能属于这些分类，不允许混合改动。

• 功能需求：重点评审业务逻辑。

• 代码重构：重点评审功能不变。

• 格式调整：通常工具检查无错误即可通过。

• 删除无用代码：重点评审向后兼容性。

（2）对可读性，包括注释加强要求，比如自动检查注释缺失。

（3）撰写足够清晰的修改描述，工具可以做一下基本格式检查。

（4）严格控制单次变更的代码量，原则上每次新增和修改的总代码行数不超过300行（删除的代码行数不受限制）。超过的话提示，强行继续发起则触发高级别评审。

3.2 评委侧

在保障代码质量的前提下，适当增加各个模块owners数量（owner 需要有相对高的高门槛机制），特别是非管理者的 owners，避免单点阻塞。通过工具自动扫描评委不足的模块。

优化选择评委，自动化指定评审人。目前是选择出owner进行自动化指定必要评审人，比如采用最小惊扰原则，自动找出所需要的最贴近的评委的最小集合，比如改动了无交集的a、b两个目录下的内容，那么只需要这两个目录下的owners都通过即可，无需惊扰更高层目录的owners。

允许发起者手动添加更高层的评委。

3.3 平台侧

（1）修改代码要通过工具开始启动，并需要选择修改的类别，关联需求单等。

（2）优化待评审列表。

• 智能排序待评审列表中按变更文件和自己所属的关系远近、最后一次评审时的变更到最后一次变更之间的变更规模、已等待时间等综合排序。也可以自己点击这些项手动排序。

• 引导评委优先评审变更规模小的、和自己关系密切的、等待时间长的变更。

• 已经关闭的和提交的评审，自动从待办列表里去掉。

• 可以考虑支持“稍后评审”机制，评委在评审变更时，如果发现此变更较大，就点击“稍后评审”，转移到“稍后评审”列表里了，这样下次再来通知不用再次分类。

（3）加强自动催办机制。

• 每次代码评审更新后，马上通知到评委。

• 通知里的链接打开待评审列表而不是具体的变更，高亮被推送的项，增加其他代码评审的曝光率，让评委顺便也评了。

• 每天2次定时或者允许适当自己选择通知时间，把待评审变更列表推送给评委。

• 关键评委催办的优先级更高（别人都评审过了，就差你了）。

（4）支持修改者在UI上人工发起催办，以便必要时进一步加快进度。

（5）支持手机评审。

• 对较小规模的代码变更，允许通过手机进行评审。

（6）自动识别变更规模的大小，加快小变更的评审速度。

（7）自动化检查。

• 琐碎错误更多用自动化方式来检查。

• 提前检查变更描述、注释等的规范性。

• 建设代码可读性自动评审工具（考察在人看来的代码复杂性而不是圈复杂度，是否必要注释缺失等）。

• 创建变更前提示/检查是否关联TAPD。

• 降低误报：收集被修改者忽略而继续发评审的检查结果，汇总分析后推动优化工具。

（8）支持TBR机制。

• To Be Reviewed，先提交后评审。

• TBR不意味着免评审，未完成的评审保留在TBR列表中，由系统催办。

• TBR上的评论，修改者需要回复确认，由平台保证。

• 原则上只允许对微小代码变更（注释，文档，UT修复，实现细节微调，清除过期FeatureFlags等）允许TBR。

• 是否允许紧急提交？待考虑（仅限非工作时间）。

（9）代码评审通过后自动合并，无需再次提交。

（10）引入度量机制。

• 对个人和团队的评审效率，有效问题发现率等进行度量和展示。

• 进行个人、团队之间的比较，对低效问题评审进行跟进。

3.4 文化侧

• 对代码修改者，宣传如何让代码修改易于被评审。

• 对代码评审者，宣传如何高效有质量地评审，鼓励驳回不合格的代码变更。

• 对代码质量高的代码作者和积极有效进行评审的评委进行奖励。