基於軟體分析的智慧化開發新型服務與技術
摘要：從雲服務廠商的角度來給大家介紹一下，當前業界圍繞該領域要做哪些事情。
本文分享自華為雲社區《基於軟體分析的智慧化開發新型服務與技術》，作者：敏捷的小智 。
本文以技術文章的方式回顧梁老師在 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 文檔了解程式碼掃描更多功能：//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 相關的服務：//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，有越來越多的開發者參與到項目貢獻中。大家可以在下面地址獲取源程式碼：//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 生態。歡迎大家到下面的地址了解並試用：
- 工具使用影片介紹：//www.youtube.com/watch?v=1b1Ap5xQHm4&feature=youtu.be
- 工具使用說明文檔：//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]
開源世界裡的數據非常大，如何進行有效過濾，發掘出真正有價值的數據，這其實是一個非常有挑戰的事情。我們在過濾環節進行了深入的探索，引入了很多指標來幫助過濾，這些指標匯總為一個洞察庫。基於洞察庫，我們孵化了一個網站：//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 工程），歡迎大家試用體驗：//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 系統，基於Android做了一系列的開發訂製，開發過程中是與Android並行的，但在項目推進到一定程度的時候需要與開源的Android程式碼進行合併，這個合併場景下衝突量會非常巨大。因此大型企業中的合併問題是一個很痛的痛點。
圍繞上述場景，我們展開了一系列研究。我們發現 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 上，大家可以關注一下：//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 上公開：//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 雲服務 //aws.amazon.com/cn/codeguru/
[2]Github Features: Security //github.com/features/security
[3]Azure Pipelines | Microsoft Azure //azure.microsoft.com/en-us/services/devops/pipelines/
[4]Debug in Visual Studio with Azure Application Insights - Azure Monitor | Microsoft Docs //docs.microsoft.com/en-us/azure/azure-monitor/app/visual-studio
[5]雲效程式碼管理 Codeup程式碼託管企業級程式碼管理平台 - 阿里雲 //cn.aliyun.com/product/yunxiao
[6]PMD - An extensible cross-language static code analyzer. //pmd.github.io/
[7]阿里巴巴自研程式碼管理平台技術解密 - 知乎 //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. //dl.acm.org/doi/10.1145/3377813.3381356
[9]CODING - 一站式軟體研發管理平台 //coding.net/
[10]Open-Source Components Definition by Law Insider //www.lawinsider.com/dictionary/open-source-components
[11]Automated Security Fixes with Dependabot - Github Security //github.blog/2019-05-23-introducing-new-ways-to-keep-your-code-secure/#automated-security-fixes-with-dependabot
[12]WePack | 獨立部署的高效製品管理服務 //wepack.coding.net/
[13]WhiteSource Report – DevSecOps Insights 2020 //www.whitesourcesoftware.com/resources/research-reports/whitesource-devsecops-insights/
[14]Top 10 Trends in Data and Analytics, 2020 - Gartner //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 //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) //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. //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. //ieeexplore.ieee.org/document/9426069
[19]The 32nd International Symposium on Software Reliability Engineering (ISSRE 2021) //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. //dl.acm.org/doi/10.1145/3360596
[21]Git Merge //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. //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. //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. //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. //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. //doi.org/10.7748/nr.12.1.82.s2
