对于企业以及开发者来说，如何选择一款好的，合适的代码评审工具至关重要，今天给大家带来的是云效Codeup代码评审的智能化建设，作者：刘力华。
点击链接：yunqi.aliyun.com/2020/sessio… ，直达9.18云栖大会云效分会场，即可免费领取云效AI研发助手。
随着人工智能技术的发展，人工智能技术已经被应用于各个领域，云效codeup团队希望将人工智能技术与研发过程相结合，去提升工程师的编码效率、评审效率以及代码的整体质量。代码评审作为研发过程中重要的一环，其主要目的是逐步提升代码库的整体代码质量，确保工程规范的一致性以及代码的可维护性。代码评审流程中的繁琐操作、复杂的代码变更、较高的人工成本等为智能化技术的落地提供了机会。同时，代码评审的智能化在学术界和工业界近几年都是比较热门的领域，学术界在变更描述生成、缺陷检测等领域产出了大量的研究成果；在工业界，Amazon发布的Codeguru工具，能在代码检测、性能分析等方面帮助评审人发现代码中的潜在问题。而我们云效Codeup平台期望通过人工智能技术为众多开发者提供高效、个性化的代码评审服务。下面我先介绍一下传统的代码评审流程。
传统评审流程
当前代码评审的评审过程主要分为创建评审、评审中、评审结束等三个阶段。开发者在日常开发过程中，为了完成某个feature，通常会进行多次代码的提交，当开发完成之后，会到代码平台创建代码评审。
在评审创建阶段，开发者需要选择源分支以及目标分支、邀请评审人、填写评审描述以及关联工作项，完成繁琐的填写操作之后，开发者才能完成代码评审的创建。评审创建完成后，代码平台会向被邀请的评审人发送邮件及钉钉通知。
评审人收到通知后会选择在空闲的时间或者固定的时间段处理待评审的变更。当评审人看到待评审列表上多个评审时，有的评审人会根据时间顺序进行评审，有的会根据评审标题进行选择，还有的会选择一个比较小的变更进行评审。评审人进入代码评审详情页后，代码平台会向其提供自动化检测的结果,如果评审人发现了代码缺陷，会通过评论的形式让开发者去修复相关问题。
评审人完成评审后，会通过该评审，如果没有代码冲突，开发者就能合并变更代码到目标分支。
评审流程问题
在传统的代码评审流程中，各个阶段都存在或多或少的用户痛点。
创建评审阶段
选择评审人:开发者通常会事先约定邀请哪些评审人来做评审，但是约定的评审人是否真的熟悉本次变更的代码？如果有多个评审人，谁更熟悉本次变更的代码？谁评审的质量又高，效率又快？如果是一个新的开发者，不知道事先的约定，应该邀请谁来评审？
填写评审信息:由于需要花费大量时间去总结本次代码变更的目的和逻辑，导致愿意填写评审描述的开发者并不多，不利于评审人了解本次评审的内容；任务、缺陷等工作项的关联也需要开发者手动选择，通常也需要花费较时间去查找。
评审阶段
查看评审列表:通常评审人会选择空闲时间或固定时间处理待评审变更，时间相对比较有限，如果评审列表里面有多个评审，评审人是否能在碎片化时间内高质量的完成评审？
选择并查看评审:如果评审的变更行数过多（通常大于500行），评审人很难充分的评审，只会看几个核心文件，容易遗漏潜在的缺陷。同时，如果邀请了多个评审人，会存在各个评审人评审职责不明确的情况，都认为对方会去评审，从而拖延了整体的评审进度。
评审并提出问题:除了人工评审之外，代码评审平台通常会集成各种代码检测工具，而现在大部分的代码检测工具都是基于规则的方式，无法发现规则之外的潜在缺陷。
评审结束阶段
冲突修复:冲突修复在评审结束阶段是很常见的场景，开发者需要花大量时间去理解冲突的代码，并找出相同和不同点，然后进行代码的合并。这个步骤会花费大量的人工时间，冲突的合并错误很可能会让待合并的代码缺失，引起线上问题。
智能评审
为了解决上述问题，我们希望借助人工智能技术去减少评审人力成本，提高评审参与度以及评审充分度。
评审创建阶段
开发者提交代码后，当需要创建代码评审时，平台会向开发者推荐适合评审本次变更的评审人，同时，会根据用户的变更信息自动生成评审描述，并推荐相关的缺陷、任务等工作项，开发者只需要少量调整即可完成评审创建。
评审阶段
当评审人访问待评审列表的时候，平台会提供每个评审的预估耗时信息，从而让评审人方便的安排碎片化时间，能在有限的时间内能仔细评审。当评审人进入某个评审之后，如果该评审的代码变更过大（比如超过500行变更），平台自动将代码变更拆分成多个分组，让每个分组只做一件事情，从而方便评审人理清思路，提高评审效率及评审充分度。同时，如果邀请了多个评审人，自动根据每个评审人对各分组代码的熟悉程度，为每个分组分配不同的评审人，从而提高评审人的参与度。在创建完代码评审的同时，平台会进行自动化的代码检测，从代码安全、质量等维度去发现代码的潜在缺陷，减少评审人的工作量，代码缺陷附带的推荐修复方案也能帮助开发者快速解决问题。
评审结束阶段
当评审人通过评审之后，如果存在代码冲突的情况，平台能自动给出针对重构类冲突的修复方案，节约开发者解决冲突的时间。
下面介绍一下上述的部分功能点。
评审人推荐
评审人选择是每次发起评审的必经过程，而从众多的库成员中选择评审人是一件耗费心力的事，用户往往通过滚动寻找或搜索来选择评审人，甚至用户不清楚谁才是适合这次评审的评审人，如果评审人不熟悉该模块的代码，需要花时间去了解整体的代码逻辑及架构，会影响整体的评审进度，也可能会遗漏一些潜在问题。代码评审人推荐通过智能化手段，基于评审人指派频繁度、代码变更熟悉度、当前分支代码评审参与度、评审评论信息、人库置信度等历史数据及用户行为偏好，向开发者推荐适合本次评审的评审人，提升了评审的创建效率，也有利于提升评审质量。
云效Codeup示例如下图所示：
评审耗时预估
评审人通常需要在开会和编码的间隙抽出一段较为碎片化的时间来做代码评审，但往往代码评审的工作量超出了评审人预期，会导致评审人为了在有限的时间内完成评审，从而降低评审标准，不会仔细评审完所有重要变更文件，为线上故障埋下了隐患。
代码评审耗时预估旨在帮助评审人在打开评审前预知本次评审的工作量，帮助他合理安排评审时间。该模块主要抽取了代码变更、代码库历史、用户行为历史等数十种特征，通过机器学习的方式对该评审进行耗时预估。其主要针对两种场景：
让用户在未点开评审之前第一时间知晓评审工作量，合理安排时间。
对于同时拥有多个代码评审的用户，评审列表上的预估耗时能帮助他们安排评审优先级。
云效Codeup示例如下图所示：
代码检测
代码检测是帮助评审人发现潜在缺陷，为开发者提供修复意见的重要工具，我们的代码平台集成了众多开源检测工具，除此之外，我们自研了敏感信息检测、代码补丁智能推荐等检测工具，覆盖了代码质量、代码安全等领域。其中代码补丁智能推荐是通过数据挖掘手段，将用于修复缺陷的相似代码变更挖掘出来，生成缺陷模板和修复补丁。当创建代码评审时，它会将当前的代码变更去匹配缺陷模板，并将历史相似的修复补丁推荐给用户。代码补丁智能推荐的相关论文已经发布至ICSE SEIP：《Precfix: Large-Scale Patch Recommendation by Mining Defect-Patch Pairs》
云效Codeup示例如下图所示：
大评审拆分
代码评审的最佳实践是小而快。经过用户调研，通常当文件变更行数超过500行时，被认为是大评审。我们了解到有些要求比较高的团队会人工进行拆分，这种方式也会增加人力成本，另外，大多数团队并不会进行人工拆分，评审人只能依靠个人经验、习惯、时间等因素去选择性评审，这会使得代码的评审并不充分。为了提升评审质量及效率，将大评审按照关联性进行拆分成多个分组，并未每个分组分配适合的评审人，可以有效的解决大评审带来的问题。目前大评审拆分正在阿里巴巴集团内试点，未来会上线到云效Codeup平台。
阿里巴巴集团内示例如下图所示：
总结
云效Codeup代码评审的智能化还在不断建设中。在未来，期望开发者能在AI研发助手的帮助下，一键发起评审，快速发现代码问题，并为开发者提供一键修复的能力。此外，云效Codeup平台的智能化建设不仅限于代码评审，智能语法服务为开发者的代码浏览提供了更方便快捷的体验，多种代码安全检测服务有助于开发者发现代码中的潜在安全风险。我们期望云效Codeup平台能为开发者带来更安全、更高效、更智能的体验。
