**摘要：**从云服务厂商的角度来给大家介绍一下，当前业界围绕该领域要做哪些事情。

本文分享自华为云社区《基于软件分析的智能化开发新型服务与技术》，作者：敏捷的小智 。

本文以技术文章的方式回顾梁老师在 SIG-程序分析技术沙龙上的分享，分享的主题是基于软件分析的智能化开发新型服务与技术。

技术趋势分析

先来看一下业界相关的技术趋势。我从云服务厂商的角度来给大家介绍一下，当前业界围绕该领域要做哪些事情。

# 缺陷检测与修复领域

首先看一下缺陷检测与修复 领域。

## Amazon - CodeGuru

Amazon 推出了一个叫 CodeGuru [1] 的 offering，其主要功能是通过全方位的缺陷检测和扫描，帮助程序员更快地识别出有问题的代码，并提供智能建议以进行代码修复。

CodeGuru: 自动执行代码审查、持续监控性能并识别低效代码，提供智能建议以提高代码质量，降低代码维护及运行总体成本 [1]

该 offering 提供了两个子服务：

CodeGuru Reviewer

顾名思义，Reviewer 子服务其实就是用机器学习的方式，通过自动化推理的算法提供智能化代码审查的服务，帮助程序员进行各种类型的代码查找，提供代码修复的建议。

CodeGuru Profiler

与其对应的另一个子服务是 Profiler。该服务更多的是利用插桩技术来监控程序运行时的状态，包括内存的消耗、CPU 的使用率等。通过分析运行时数据，提高程序的运行效率，甚至帮助程序员找到运行成本高昂的代码行。

## Microsoft - Azure

我们再来看一下微软的 Azure。

Github Code Scanning

Github 作为一个代码托管平台，同时也是全球最大的代码数据中心之一。围绕这个中心，Github 开展了各种各样的代码分析服务。微软收购 Github 之后，Azure 和 Github 进行了充分的集成，其中就包括了 Github 的 code scanning [2] 服务，可以在 Azure 上针对高危的 security issues 提供扫描的能力。

如下图示，在 Github 的代码提交页面上，Code Scanning 会自动地将识别到的缺陷告警显示在页面上，帮助程序员更快地去发现问题，从而在代码入库前拦截掉这些问题。

Github Code Scanning [2]

Pipeline

除此之外，Azure 的 Pipeline [3] 也支持配置各种类型代码扫描的任务。与其他云厂商思路不同的是，Pipeline 的缺陷分析工具并不是由微软自己来提供，用户可以自由地配置外部的 static analyzer。例如，用户可以在本地部署一些静态分析的服务，在 Azure 里配置相关的链接，包括扫描的命令等，从而将本地和云端进行一个有机的集成。

支持设置代码扫描任务，覆盖主流缺陷检测工具 [3]

Monitor within Visual Studio

与此同时，微软也在不断地繁荣自己的代码分析能力。如下图示，Visual Studio 提供了一些监控的手段，用来帮助程序员更快地识别程序里的潜在问题，并给出更新提示。这其实和刚才提到的 Amazon CodeGuru Profiler 有类似之处。

通过监控识别潜在性能问题，并给出优化建议 [4]

## 阿里云 - CodeUp

阿里云通过 CodeUp [5] 代码托管平台，也有在持续地拓展软件分析的能力。

依托 PMD 和 Sonar 插件完成合规检查

CodeUp 主要依托 开源代码扫描工具 PMD（Programming Mistake Detector）[6] **和 Sonar 插件（主要用于代码库全量自动化扫描阶段）**来完成相关的合规检查。

代码质量 - 规约检测 P3C [7]

融合 AI 提供自动修复 / 敏感信息检查 / 评审智能化

阿里云在 ICSE-SEIP’20 上发表了代码自动修复技术 PRECFIX [8]，能够基于数据挖掘的方式做模式挖掘，从而提供代码修复能力。

代码质量 - PRECFIX [7]

提供多层敏感信息检测工具。

代码安全 - 敏感信息检测 SecretRadar [7]

提供代码智能评审，以提高程序员研发效率。

研发提效 - 智能评审 [7]

## CODING 平台

CODING [9] 平台（腾云扣钉科技有限公司，腾讯旗下全资子公司）也提供了代码扫描的能力。CODING 目前在内部集成了多种代码扫描工具、数千条规则，提供了很多主流编程语言的漏洞检测和修复的能力，同时支持用户配置方案，支持集成外部工具。

CODING 提供了分支代码质量分析的功能，可以帮助管理者快速了解分支的代码质量，例如：

分支概览

圈复杂度

查看 CODING 文档了解代码扫描更多功能：https://help.coding.net/docs/code-scan/intro.html

## 小结

• 国内该类 DevOps - 检查产品还不够成熟，目前各大云厂商也是初步布局阶段，尚未形成稳定格局，市场机会尤在
• 企业设施云化、数字化转型趋势下，软件质量（可用性、可靠性、安全、韧性）属性关注度将日益增强
• 主流云服务厂商，目前全部涉足该领域，对代码缺陷检测与修复关注度持续增强，进一步确认了该研究方向的投资价值和必要性
• 阿里围绕缺陷修复数据挖掘有研究成果发布，微软提供了 CodeQL 查询语言等，进一步确认了该项目关键技术路径（基于用户修复数据进行历史学习、基于 dsl 等提高缺陷检测能力可扩展性等）的合理性

# 开源成分治理领域

在这个部分我们介绍一下开源成分（即 Open-Source Components [10]）治理。前面讲到的缺陷分析领域，更多是针对程序员自己开发出来的代码来分析，看里面是否有各种类型的问题。而开源成分更主要是围绕程序员在开发的过程中，可能大量复用的外部第三方的开源成分。

现代软件开发中开源成分的使用比例与日俱增，业界关注度也越来越高。那么，结合了开源成分的代码应该如何进行质量的保障？其实这也是需要通过一系列的智能化开发服务，或者软件分析服务来做到的。

那么，在开源成分治理领域，相关的云服务厂商正在做哪些实践呢？

## Microsoft Azure - Github Dependabot

我们还是先来看一下微软的 Azure。微软在 Github 上通过 Dependabot [11] 服务，针对代码仓里用到的三方库成分进行扫描。具体来讲，Dependabot 会先扫描出来代码仓里具体依赖了哪些三方库的成分，然后针对 Top 级的或者一些已知的漏洞列表，进行漏洞的关联和预警。

在这个过程中，结合漏洞扫描的数据，Dependabot 还可以推荐一些漏洞修复建议，引导程序员更快地去修复掉带有漏洞的库。

## 阿里云 - CodeUp

阿里云的 CodeUp 也在做类似的事情。

当前 CodeUp 主要是针对系统层面的中间件级别做成分分析，比如服务器层面的基础设施是否存在安全隐患，还没有在代码层面上展开工作。如果某一个特定中间件的某个特定版本存在漏洞，CodeUp 会及时给出预警。这也是阿里云整个基础设施里比较关键的一部分功能，能够为客户的 server 层面、虚拟机层面的安全能力进行保驾护航。

Web 扫描器

仅支持检测在云安全中心防护范围内（即已安装云安全中心 Agent）可以访问公网的服务器，支持阿里云和非阿里云的服务器。

Web 扫描器

服务器组成成分分析

支持检测云安全中心防护范围内的阿里云和非阿里云服务器；防护范围非常有限，能力处于初级阶段。

服务器组成成分分析

## 腾讯云 - WePack 制品扫描

腾讯云 WePack [12] 提供了制品扫描的能力，扫描的对象更多是针对编译后的编译包。

WePack 制品仓库目前支持的制品类型

WePack 通过对解压缩后的二进制组件进行审视和定位，找出每个组件到底是来自于哪个开源社区的开源项目。在定位出来之后，WePack 会对组件进行漏洞关联，并针对高危的和一些中危的漏洞进行提示，帮助程序员更快地发现组件里的漏洞信息，并及时修复。

制品扫描支持制品类型，以 Maven 为例

## 小结

• 软件中开源成分与日俱增（开源成分比例 70%+，WhiteSource 20 年报告 [13]），开源成分管理成本日益严峻，亟需工具支撑
• Gartner 2020 报告 [14] 预计到 24 年，50% 的软件客户都需要软件提供商提供软件 BOM 清单。SCA 能力将会越来越普遍的得以应用，成为刚性服务
• 主流云服务厂商，目前大部分已涉足该领域，但目前提供的技术还处于早期阶段，待进一步完善增强，进一步确认了该研究方向的投资价值和必要性
• Github 提供了库升级助手、阿里云提供了漏洞预警服务等，进一步确认了该项目关键技术路径（基于开源社区数据进行库升级替换模式挖掘、库移植场景代码自动化适配等）的合理性

华为云相关技术实践

那在完成了相关技术的梳理之后，我们来看一下华为云正在做哪些技术实践。

# 缺陷检测与修复

## CodeCheck

华为云的 CodeCheck 结合华为的通用编程规范和安全编码规范，构建了 3 级检查 + 3 层运营的检查与修复体系。

3 级检查机制

首先，我们需要有一些对应公司编码规范的能力或者工具集来帮助程序员进行符合公司编码规范的检查。因此围绕这个需求，我们打造了 CodeCheck 平台。CodeCheck 当前已经在全公司范围内落地，也就是说每个华为的程序员在代码提交入库时，都会经过 CodeCheck 系统的扫描和诊断。

如上图示，CodeCheck 针对代码检测进行了多方位多角度的支撑，包括：

• IDE 级 我们提供多种 IDE 的插件，程序员可以在写完代码之后，及时进行缺陷扫描和代码修复。除此之外，我们还提供了一些自动化修复的能力。
• 门禁级 鉴于门禁时间不能太长，整个的分析时长需要控制在分钟级。所以在这一级，我们精选了一部分准确率比较高、运行时间比较短的能力集成到门禁里。门禁级提供系统化的扫描。
• 版本级 在最后出版本的时候，我们会提供全量分析的能力。

上述三个阶段会形成互补，来全方位地保障华为内部项目代码的质量。

在不同阶段，CodeCheck 的分析有不同的要求：

3 层运营机制

CodeCheck 还提供了 3 层的运营体系：

• **公司层 **会制定整体的代码质量体系，包括应该遵循什么样的流程和规范，工具应该怎么落地和使用，需要提供出一个缺陷检测的最小集合。
• **产品线层 **在公司层之下，每个产品线会根据自己问题域的一些特定要求来定义不同的规则集，也就是说，在不同的产品线，规则集其实存在一定的可调整范围，产品线可以针对自有特点来制定合适的规则集。另外，产品线也会给产品层提供指导，并定义一些公共的规则。
• 产品层 具体到每一个产品，其规则又允许进行一定程度的定制和数据治理。鉴于静态分析工具会存在一些误报的场景，当误报发生时需要产品自建屏蔽库来做一系列排查、标记和屏蔽的工作。

CodeCheck 现已通过华为云的 DevCloud 向公司外用户提供，大家可以来试用 CodeCheck 相关的服务：https://www.xzssit.com.cn/support/codecheck/

## diKTat

在 CodeCheck 平台之上，我们还做了很多探索，其中之一就是我们在 2020 年与俄罗斯团队一起合作打造的一款静态分析工具 —— diKTat [15]，该工具主要是针对 Kotlin 提供轻量级的代码分析。

Approach

dikTat 主要的原理是对接收的源代码做一系列的 AST 扫描。在这里我们用到了 PSI 结构，在这个结构上通过 visitor 模式进行遍历，从而支持 code style 的整改以及一些公共规则的检查。

dikTat 原理概览

PSI 结构示例

另外，Kotlin 之前的静态分析工具都依赖 Type-Resolution analysis，其分析成本比较高，相对来说使用效率会低一点。与之不同的是，dikTat 提供了 No-Type-Resolution analysis，在不进行 type resolution 的情况下，利用一些启发式的规则来做分析。

Evaluation

经过实验证明，dikTat 能够在多个任务上进行有效的分析，包括 code style 分析、formatting、基于 common coding rules 的检测、代码坏味道检查等。

Achievements

dikTat 已发表在 ISSRE 2021 [16]。

我们将项目在 Github 上开源，当前已获得 280 个 star，有越来越多的开发者参与到项目贡献中。大家可以在下面地址获取源代码：https://github.com/cqfn/diKTat

另外，dikTat 经过短短半年时间的工作，现已被 Kotlin 社区所采纳。在静态分析的网站 [17] 上可以看到，dikTat 已成为了 Kotlin 官方认可的三个主要的工具之一。

# 开源治理：三方库移植（升级/替换）

接下来，围绕开源治理方面。我简单介绍一下我们做了哪些探索。

我们当前重点投入的是 三方库相关的问题诊断和修复，即因三方库存在的漏洞，或其他方面的问题，导致项目中不能继续使用的情况下，我们该如何快速地进行升级或替换。

## 移动应用智能移植（from GMS to HMS）

背景挑战

我们先看一个初步的尝试。

由于一些市场因素，华为终端需要打造 HMS（即 Huawei Mobile Service）生态。在这个过程中，存在一个问题，即海外市场的应用大部分都是基于 GMS（即 Google Mobile Service） 开发的，那么现有的应用如何才能够快速迁移到 HMS？我们不能够要求程序员重新写一套应用，所以我们希望给开发者提供一个比较快捷高效的工具，帮助他们将基于 GMS 的应用快速迁移到 HMS 生态。

问题分析与解决

针对这个问题场景，我们与华为内部多个部门，联合打造了一个移动应用智能移植应用。该应用的主要架构如下图所示，假设我们存在一个待转换的 GMS 应用，第一步需要在应用内部识别出它调了哪些 GMS 接口，然后在 GMS SDK 层面将调用的接口自动对应到 HMS SDK 上，并自动化地将 HMS SDK 上相应的 API 适配到应用的接口调用处，从而完成整个的转换。

完成结果

该应用作为 HMS Toolkit 里的核心能力之一，已在 2020 年正式发布，帮助我们更快地构建 HMS 生态。欢迎大家到下面的地址了解并试用：

• 工具使用视频介绍：https://www.youtube.com/watch?v=1b1Ap5xQHm4&feature=youtu.be
• 工具使用说明文档：https://developer.huawei.com/consumer/cn/doc/development/Tools-Guides/convertor-0000001050147221

全面开放 51 项服务 885 个 API

## 不可信三方库的智能移植

GMS 到 HMS 只是一个库的移植，我们可以将上一个工作的移植能力泛化到开源三方库的治理上，提供有风险的三方库自动化修复能力，这就是我们当前正在做的一个工作。

我们收集了大量开源项目代码仓的数据，基于这些代码仓的原始数据构建开源项目知识图谱，例如某个项目发布了哪些版本，哪个版本对应的是哪个 commit，每个 commit 发布 API 有哪些，这个项目中使用了哪些三方库等。当所有代码仓的关联关系构建起来后，我们就可以在上面做很多数据挖掘的工作。比如，我们可以针对业界主流库的一些低版本或有漏洞的版本做挖掘，看看社区是如何修复的漏洞，或者用到了哪些库来替换这些有风险的库。

### 核心技术点 1：开源库替换模式挖掘技术

这就是我们在做的第一个工作，即找出库之间的替换模式，从而为后续风险三方库的替换及修复带来一些洞察。

Approach

我们的大概思路如下图示。针对每个开源项目的历史做挖掘过滤，计算出每一个项目的三方库演进历史（即项目的依赖变更序列）。得到变更序列之后，引入序列模式挖掘算法。在这个过程中，我们会结合一定的指标对结果进行过滤，包括热门库识别、时间修正等，从而保证模式的准确率。

开源库替换模式挖掘技术

目前我们已经挖掘到 1400 多个有效的替代模式，这个工作在 2020 年中国软件大会上获得了三等奖。

Implementation

我们在 SANER 2021 上发表了 “A Multi-Metric Ranking Approach for Library Migration Recommendations”，在前面工作思路的基础上，引入了更多的指标来做数据过滤。下图是这个工作的实现：

A Multi-Metric Ranking Approach for Library Migration Recommendations [18]

开源世界里的数据非常大，如何进行有效过滤，发掘出真正有价值的数据，这其实是一个非常有挑战的事情。我们在过滤环节进行了深入的探索，引入了很多指标来帮助过滤，这些指标汇总为一个洞察库。基于洞察库，我们孵化了一个网站：http://migration-helper.net/

下图是洞察库当前的进展。大家可以看到，这个洞察库一直在持续地演进和增强，网站页面会实时显示由 experts 确认后的 Migration 建议。用户可以在这个网站查询到，一些已知的风险三方库，业内大部分人迁移到了哪个三方库上。我们通过数据挖掘的方式提供给大家一些建议，从而提高开发者修复风险三方库的效率。

### 核心技术点 2：库替换场景 API 适配模式挖掘技术

有了替换模式其实还不够，当你把一个库 A 替换到库 B 之后，问题来了，这个两个库之间的 API 可能是不兼容的，这种情况下我们应该怎么办？我们基于前面的挖掘工作进行了进一步的探索，即库替换场景下的 API 适配模式挖掘。

这个工作也需要基于历史数据来挖掘，即当这个库发生变化和迁移时，我们尽可能地将上层代码的变更记录提炼出来，通过形式化方法的技术，去 specify API 的适配模式，我们会对这样的模式进行挖掘，并把它以图的结构记录到系统里。下图是一个简单示例，大家可以去阅读我们和俄罗斯团队联合发表在 ISSRE 2021 的最新论文 [19] 了解更复杂的实现细节。

库替换场景 API 适配模式挖掘技术 [19]

Approach

下图是该工作的 approach overview。当有了变更动作后，我们会进行一系列的数据挖掘处理，包括数据的拆分、最小化、聚类、提纯等，最后得到模式集，保证最终结果的有效性。

Pattern Mining Scheme

Example

这是一个从 org.json 替换到 google.code.gson 的具体示例。我们将这个示例中的代码变换进行一系列的处理与挖掘，得到右侧两个 change pattern。后续若有程序员遇到类似库替换的场景时，我们就可以通过应用 pattern 来自动地做代码适配。

大家可以看到，pattern 使用了不同的 node 来记录变更的动作，包括一些代码的增加 ActionInsertAfter 和删除 ActionDelete 都刻画在这个结构中。

Evaluation

我们在一些开源典型场景上做了实验，结果表示我们的方法能够挖掘出很多有效的 patterns，如下图左所示。我们将挖掘出的 patterns 还原到实例中，评估 patterns 的质量（主要是覆盖率），结果如下图右所示，我们的方法在很多场景下还是有价值的，在大部分场景下适配的准确率可以达到 70% 以上。

Implementation

我们已将上述工作集成到了 CodeCheck 中，近期有发布一个 CodeCheck IDEA 插件试用版（当前仅支持 maven 工程），欢迎大家试用体验：https://bbs.huaweicloud.com/blogs/285414

下图是插件使用的一个示例。

安装插件：打开 IDEA 插件市场离线安装界面，选中安装包单击。

扫描项目依赖：右键点击项目根目录或者构建文件，点击 CodeCheck->Check Third-Party Libs 查看项目所有带漏洞的依赖。

查看关联漏洞：左键单击表格第二列可查看具体漏洞信息。漏洞信息由内部的漏洞收集平台提供，经过内部评审。

库修复预览：选中修复建议后，点击 Preview 按钮可以预览自动适配。

库修复适配：点击 Apply 按钮可以应用选中的适配（当前仅支持构建文件的自动适配）。

在 IDEA 里安装完插件后，右键 maven 项目可以看到 CodeCheck -> Check Third-Party Libs 菜单选项，该选项用于检查 maven 项目中应用到的三方库。触发该选项后，后台会自动分析项目的 dependencies，通过匹配漏洞库的数据，对匹配上的三方库给出预警。

上面示例中，该项目依赖的三方库被检测出存在一系列漏洞，用户可以点击查看漏洞详情。当用户确认是漏洞后，可以使用 Fixing Actions 来对漏洞进行自动化/半自动化的修复。我们提供 Preview 功能预览修复前后的对比，Apply 功能将修复建议应用到项目中，Revert 功能回退修复改动。

# IntelliMerge 代码智能合并

接下来，简单介绍一下我们的代码智能合并创新工作 IntelliMerge，该工作是我们与北大研究团队在 OOPSLA’19 的联合研究成果 [20]。

## Motivation

现代软件开发，越来越多的是以团队作战，团队的代码需要定期做同步，合并，以及提交。尤其是大型企业中，程序员会面临非常复杂的合并场景，一是团队规模越来越大，二是项目中可能会复用大量开源代码。

比如华为的 EMUI 系统，基于安卓做了一系列的开发定制，开发过程中是与安卓并行的，但在项目推进到一定程度的时候需要与开源的安卓代码进行合并，这个合并场景下冲突量会非常巨大。因此大型企业中的合并问题是一个很痛的痛点。

围绕上述场景，我们展开了一系列研究。我们发现 Github 其实已经提供了一些 merge 的能力，支持程序员在很多的分支之间做代码的合并。但是，Github 并没有去理解代码本身，而更多地把代码作为文本去处理，判断合并是否有冲突，应该如何合并。

Github Merging between branches

业界 Merging 技术

学术界针对合并技术已经有了很多的工作，并且也有越来越多的人开始关注这个领域：

• Unstructured/Textual: GitMerge [21] (Text-line based), most popular，Github Merge 采用的技术

• Semi-structured: jFSTMerge [22] (Tree based), OOPSLA2017

• Structured: AutoMerge [23] (AST based), OOPSLA2018，成本极高

当 Merging 遇上 Refactoring

调研发现，传统合并技术还有很多问题亟待解决。以重构为例。

在大型项目中，我们会一定频率上地进行代码的重构 refractoring，整个代码的变化会非常大，你甚至可能会将一个方法抽象到它的父类上，或者将一个方法进行移动，而实际上整个代码的语义并没有发生变化。传统的合并技术并不理解代码层面的操作，所以无法判断改动前后语义是否等价。

因此我们会发现，在重构的场景下，传统的 Merge 算法都会失效，尤其是最为广泛应用的 GitMerge。这会导致合并的结果非常糟糕，合并后的代码很可能存在一定语义方面的问题（False Negative），没有解决的冲突也不一定是真冲突（False Positive）。

Refactoring-Aware Merging

我们提出了一个 “Refactoring-Aware Merging” 的概念，尝试去理解代码的变更，从而判断代码是否进行了重构。

若重构发生，我们会通过代码理解的技术去推导出重构的行为，例如，代码的变动是一个上移的行为（push down） 还是一个下移的行为（pull up），亦或是代码片段的提取（extract）？当重构的行为被识别出来后，我们会对同一个代码片段进行更细粒度的匹配。匹配完成后，再将传统的 merge 算法应用到代码片段上，从而更加精准地合并代码。

## Approach

下图是我们工作的大概思路：

• **Step 1: Code-to-Graph **针对源码文件的三个版本（base，left by developer A，right by developer B），进行代码分析，构建出对应的 PEGs（Program Element Graphs)
• Step 2: Matching 对 PEGs 进行节点匹配（vertices matching），将相同节点的代码块关联起来
• Step 3: Merging 关联之后，在每一个节点上对具体的代码块做合并，输出合并后的代码文件

IntelliMerge: The graph-based and refactoring-aware semi-structured merging tool for java. [24]

## Evaluation

这是该工作的实验结果。

对于冲突代码块（Conflict Blocks），实验结果表明，我们的方法能够大量降低潜在冲突块的数量。

对于合并后的代码（Merged Part），相比 jFSTMerge 与 GitMerge，IntelliMerge 准确率（precision）有一定的下降，但 recall 是提高的（IntelliMerge 尽可能地帮助程序员自动合并了更多的代码块）。因此整体来讲，IntelliMerge 的收益是更大的，在很小准确率损失的情况下，节省了很多程序员的时间。

The precision and recall of the three merging tools on auto-merged code.

这个工作我们已开源在 Github 上，大家可以关注一下：https://github.com/Symbolk/IntelliMerge

注：precision 和 recall 的计算公式如下

# SmartCommit 代码提交智能分拆

最后介绍一下我们有关 代码提交智能分拆 的研究成果** SmartCommit [25]**，我们在最近的 FSE 2021 会议上进行了报告，并很荣幸地获得了最佳论文奖。

## Motivation

现在企业内部就成提交代码的时候，程序员代码的提交往往没有有效管控工具，来判断他的提交是否满足高内聚低耦合的原则。

我们希望代码的每次提交都可以保持只做一件事情。比如，在这个提交内只做 formatting，或者只做某个 bug fix，或者只支持了某一个 new feature。

这是我们期望的：

高内聚提交 Cohesive commits

而实际上，我们针对公司内外很多项目做了大量的调研和分析，发现其实 commit 历史记录中会包含大量的所谓 组合式提交，即一个 commit 里包含了多个任务。根据统计数据来看，这种类别的提交记录占比 11%~40%（MSR13/15 for open-source communities，ICSE15 for companies），这会大大提高项目的维护成本。

这是我们不提倡的：

组合式提交 Composite commits

## Approach

基于这个场景，我们希望能够针对用户提交的 commit 做智能的理解，判断它是否混杂了多个开发任务，基于代码分析的技术将 commit 拆分为多个原子型的 commit groups 或者 change groups。鼓励程序员能够单独的去提交每个 change group。（围绕这个工作我们还做了延展，比如程序员在提交的时候，commit message 该如何撰写，如何更规范地写 message，commit 应该归为 refractor/bug fix/new feature？）

SmartCommit 将代码分析的技术与图匹配的算法融合为一个图分拆算法，会给程序员提供拆分 commit 的建议，尽量保持每个 commit 满足高内聚低耦合原则。下图是实现思路。

## Implementation

基于上述实现思路，我们提供了一个公开的系统，源代码已在 Github 上公开：https://github.com/Symbolk/SmartCommitCore

我们将这个系统实现为一个工具，通过图形化界面可以很清晰地给程序员提示，比如当前 commit 混杂了很多的开发任务，每一个任务是什么，每个任务对应的 change 是什么。程序员可以在这个工具上进行快速确认，若不认可工具的某些拆分，还可以手动整合一些 change group，调整完成后，工具还可以自动地将这些 change groups 提交。这样，一个 composite commit 会几乎自动地被拆分为多个满足高内聚原则的 cohesive commits。

## Evaluation

我们采用了混合式方法进行实验评估：

Industrial Field Study 我们在华为内部的两个项目上做了近 9 个月的实验，邀请华为内部的程序员使用这个工具，同时监测程序员对工具结果的反馈，看他是否采纳了工具给出的建议，并依据建议作出修订。

Controlled Open-Source Experiment 我们在开源项目上也做了一些实验。

并通过三角分析 [26] 增加我们对实验结果的信心：

准确率结果如下：

Industrial Field Study

Controlled Open-Source Experiment

结果表明，工具给出的建议可能不是完全正确的，往往需要程序员做一些微调。但工具可以给程序员提供一个比较好的起点，可以很快速的引导程序员做出更加规范的提交。

一些思考

最后，围绕智能化的可信软件开发这个话题，谈一谈我们软件分析 Lab 当前的一些思考。

其实在软件开发的很多环节里，都可以将程序分析这个技术嵌进去，比如：

编码环节 包括常见的注释生成，程序生成，代码搜索等，还有今天提到的 API 迁移、代码检查修复，开源成分治理等

单元测试 围绕这个方面，我们也有在做一些探索，希望可以自动化地生成一些单元测试用例，来提高研发效率

**代码检视 **通常与代码检查、代码修复结合在一起

代码合入 代码的智能合入与冲突消解、智能提交、智能同步、智能 cherry-pick

系统运维 智能补丁筛选等

其实在软件开发的整个生命周期里，程序分析技术都发挥了非常关键的作用，甚至已经在逐渐地扮演根技术的角色。十分开心能有这样一个技术沙龙，希望 **SIG-程序分析**可以吸引更多的老师、同学、业界同仁一起来探讨程序分析更多的话题。

我的报告就到这里，感谢大家。

参考

[1]Amazon CodeGuru - 可自动执行的代码审查服务 - AWS 云服务 https://aws.amazon.com/cn/codeguru/

[2]Github Features: Security https://github.com/features/security

[3]Azure Pipelines | Microsoft Azure https://azure.microsoft.com/en-us/services/devops/pipelines/

[4]Debug in Visual Studio with Azure Application Insights - Azure Monitor | Microsoft Docs https://docs.microsoft.com/en-us/azure/azure-monitor/app/visual-studio

[5]云效代码管理 Codeup代码托管企业级代码管理平台 - 阿里云 https://cn.aliyun.com/product/yunxiao

[6]PMD - An extensible cross-language static code analyzer. https://pmd.github.io/

[7]阿里巴巴自研代码管理平台技术解密 - 知乎 https://zhuanlan.zhihu.com/p/140425680

[8]Xindong Zhang, Chenguang Zhu, Yi Li, Jianmei Guo, Lihua Liu, and HaoboGu.  Precfix: Large-scale patch recommendation by mining defect-patch pairs.InProceedings of the ACM/IEEE 42nd International Conference on SoftwareEngineering: Software Engineering in Practice, ICSE-SEIP’20, page 41–50,New York, NY, USA, 2020. Association for Computing Machinery. https://dl.acm.org/doi/10.1145/3377813.3381356

[9]CODING - 一站式软件研发管理平台 https://coding.net/

[10]Open-Source Components Definition by Law Insider https://www.lawinsider.com/dictionary/open-source-components

[11]Automated Security Fixes with Dependabot - Github Security https://github.blog/2019-05-23-introducing-new-ways-to-keep-your-code-secure/#automated-security-fixes-with-dependabot

[12]WePack | 独立部署的高效制品管理服务 https://wepack.coding.net/

[13]WhiteSource Report – DevSecOps Insights 2020 https://www.whitesourcesoftware.com/resources/research-reports/whitesource-devsecops-insights/

[14]Top 10 Trends in Data and Analytics, 2020 - Gartner https://www.gartner.com/account/signin?method=initialize&TARGET=http%253A%252F%252Fwww.gartner.com%252Fdocument%252F3984974

[15]diKTat | Strict coding standard for Kotlin and a custom set of rules for detecting code smells, code style issues and bugs https://www.cqfn.org/diKTat/

[16]Diktat: Lightweight Static Analysis for Kotlin. Andrey Kuleshov (Huawei Technologies Co., Ltd), Petr Trifanov (Huawei Technologies Co., Ltd), Vladislav Frolov (Huawei Technologies Co., Ltd) and Guangtai Liang (Huawei Technologies Co., Ltd) http://2021.issre.net/industry-accepted-papers

[17]A curated list of static analysis (SAST) tools for all programming languages, config files, build tools, and more. https://github.com/analysis-tools-dev/static-analysis

[18]H. He, Y. Xu, Y. Ma, Y. Xu, G. Liang and M. Zhou, "A Multi-Metric Ranking Approach for Library Migration Recommendations," 2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2021, pp. 72-83, doi: 10.1109/SANER50967.2021.00016. A Multi-Metric Ranking Approach for Library Migration Recommendations | IEEE Conference Publication | IEEE Xplore

[19]The 32nd International Symposium on Software Reliability Engineering (ISSRE 2021) https://issre.net/

[20]Bo Shen, Wei Zhang, Haiyan Zhao, Guangtai Liang, Zhi Jin, and QianxiangWang. Intellimerge: A refactoring-aware software merging technique. Proc.ACM Program. Lang., 3 (OOPSLA), October 2019. https://dl.acm.org/doi/10.1145/3360596

[21]Git Merge https://git-scm.com/docs/git-merge

[22]Guilherme Cavalcanti, Paulo Borba, and Paola Accioly. 2017. Evaluating and improving semistructured merge. Proceedings of the ACM on Programming Languages 1, OOPSLA (2017), 59. https://dl.acm.org/doi/10.1145/3133883

[23]Fengmin Zhu and Fei He. 2018. Conflict resolution for structured merge via version space algebra. Proceedings of the ACM on Programming Languages 2, OOPSLA (2018), 166. https://dl.acm.org/doi/10.1145/3276536

[24]Bo Shen, Wei Zhang, Haiyan Zhao, Guangtai Liang, Zhi Jin, and QianxiangWang. Intellimerge: A refactoring-aware software merging technique. Proc.ACM Program. Lang., 3(OOPSLA), October 2019. https://dl.acm.org/doi/10.1145/3360596

[25]Bo Shen, Wei Zhang, Christian Kastner, Haiyan Zhao, Zhao Wei, Guangtai Liang, and Zhi Jin. Smartcommit: A graph-based interactive assistant for activity-oriented commits. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/FSE 2021, page 379–390, New York, NY, USA, 2021. Association for Computing Machinery. https://dl.acm.org/doi/abs/10.1145/3468264.3468551

[26]Alison Twycross. 2004. Research design: qualitative, quantitative and mixed methods approachesResearch design: qualitative, quantitative and mixed methods approaches Creswell John W Sage 320 £29 0761924426 0761924426. Nurse Researcher 12, 1 (sep 2004), 82–83. https://doi.org/10.7748/nr.12.1.82.s2

点击关注，第一时间了解华为云新鲜技术~