在知乎上開了一個專欄，準備不定期更新系列文章介紹缺陷修復技術。本文是第一篇，主要介紹缺陷修復研究的意義。後續計劃內容還包括缺陷修複目前的技術體系介紹和主要挑戰總結。歡迎各位讀者留下寶貴意見。

缺陷修復技術介紹

缺陷修復技術大概是從2000年開始有較多研究。最早的研究集中在演化缺陷修復，即如何在軟體製品被修改的時候自動修復演化引入的不一致缺陷，產生了雙向變換等技術。後來的研究重心轉到了更通用的程序缺陷修復上，即給定一個程序和一個該程序不滿足的規約（可以是不完備的規約，比如測試等），研究如何自動的生成程序上的補丁使得該程序滿足規約。

目前，程序缺陷修復的研究已經吸引了軟體工程、程序語言、人工智慧、形式化驗證等四個社區的大量研究人員投入。根據社區網站http://program-repair.org統計，僅2017一年就有39篇缺陷修復論文發表在各個不同領域的主流會議上。

研究缺陷修復的產業意義

當前缺陷修復技術在產業界的主要作用是輔助程序員修復缺陷，提高缺陷修復的效率和質量。缺陷修復是軟體開發過程中的主要活動之一。比如軟體工程的部分經典文獻表明，軟體維護占軟體成本的90%以上[8]，而軟體維護中35.6%的活動都是在修復缺陷[9]。而來自2013年劍橋大學的一份報告更是估算現代軟體開發中缺陷修復佔用成本達到了50%[10]。已有研究表明[1]，當程序員有自動生成的高質量補丁作為參考時，修復的效率和質量都有顯著提升。

一項技術有沒有產業意義，其實看各個大公司的行動就比較清楚了。從我回國發表了一批缺陷修復論文之後，就不斷有國內公司和研究所找我交流缺陷修復的相關技術。就我目前了解的情況，華為和阿里都有較大的團隊專門從事缺陷修復工具的開發，360公司和多個航空航天的研究所都有專人跟蹤研究缺陷修復技術，有沒有開發工具尚不清楚。

最初交流的時候，我其實對應用價值也有疑惑的：按目前缺陷修復技術的發展水平，能修復的缺陷只佔全部缺陷的很小一部分，你們為什麼不等到學術界研究更成熟之後再採用這些技術？最早把我說服的是華為的工程師：你看，我們華為公司幾萬名程序員，每人每天都花大量的時間在修復缺陷。哪怕是只能自動修復1%的缺陷，給每名程序員節省千分之一的開發時間，對於整個公司來說就是每年千萬元級的成本節省。後來阿里等公司的工程師也表達了類似的觀點。

除了節約成本，很多航空航天的研究所向我強調的是缺陷修復在提高軟體質量上的作用。程序員修復缺陷的時候很可能引入其他缺陷。以我們開發的內存/資源泄漏修復技術為例，雖然現在有很多工具都能查找內存泄漏，但修復內存泄漏仍然是比較困難的，一不小心就會引入重複釋放（double-free），使用前釋放（use-after-free）等問題，而這些問題都會直接導致程序崩潰。在實踐中，常常出現在軟體發布前發現了內存泄漏，開發團隊連夜開會討論卻最終決定保險起見不修復的情況。而採用我們的技術，可以保證找到的補丁都是安全的，即確保不會出現上述問題，從而提高了軟體的質量。

另外，最近一些航空航天領域的學者甚至開始設想一個全新的應用場景。在衛星等無人值守的航天設備中，有時會出現發射之後因為軟體缺陷失聯的情況。一旦無法聯繫，相當於上億的投入就打了水漂。如果能在衛星內植入一套缺陷修復技術，在衛星出現故障的時候試圖自動修復軟體的缺陷，至少有一定概率能救回這些衛星，也就提高了整體系統的健壯性。

除了國內公司，海外大公司也在缺陷修復技術持續投入。谷歌是這方面的先行者之一。在發表在Communications of ACM上的論文[2]中，谷歌公司的工程師認為修複檢查出的缺陷是一項昂貴(expensive)和高風險(risky)的工作，並率先開發了支持修復的缺陷檢查工具Tricorder[3]。而富士通更是投入了大量力量開展缺陷修復研究，有多篇修復領域的前沿論文都來自於富士通公司[4-6]。最近，Facebook也公布了自己的缺陷修復工具SapFix，用於修復安卓的缺陷修復。

事實上，我們團隊的修復技術也已經被應用到了多個領域。國內某頂級IT企業已經和我們完成了一期合作，我們的工具已經在該企業內部測試環境檢查超過數百萬行代碼並修復了多處缺陷。目前我們正在討論第二期面向更多缺陷類型的下一步合作。Linux社區的新一代內核配置工具開發項目已經選用了我們的互動式配置修復技術，相關項目負責人在調研了多個配置修復技術之後，認為我們的技術是「最實用的技術之一」。我們的技術還在其他多家企業和學術項目中有應用，同時非常歡迎業界和我們討論技術合作。

研究缺陷修復的學術意義

已故軟體領域學術泰斗徐家福先生很早就指出提高軟體生產率的根本途徑是軟體自動化[7]，即儘可能自動化軟體開發中的各項活動。徐先生對於軟體自動化給出了廣義和狹義兩方面的定義。廣義包括自動化軟體開發中的各項活動，即包括分析、設計、編碼、測試、調試、修復等各項活動。而更核心的狹義定義就是只自動化從軟體需求規約到代碼的過程。實現軟體自動化一直是軟體學科研究人員的最高理想之一。

同徐先生研究軟體自動化的年代不同，現代計算機學科的發展對軟體自動化提出了更強的需求。目前是一個計算機技術高度發展的年代，在各行各業，數字設備都在取代傳統設備，而數字設備越來越多地依賴軟體控制，也就是說，各行各業都有大量的軟體需求。面對這些需求，有限的程序員數量將會是制約產業發展的重要因素。通過軟體自動化，從根本上提高軟體生產率，有望大幅緩解這一制約的矛盾。

現在我們回到缺陷修復。一方面，缺陷自動修復技術屬於廣義的軟體自動化技術。另一方面，在我看來，研究缺陷修復更是實現狹義軟體自動化的有效途徑。在現代開發過程如敏捷開發中，軟體開發是一個不斷修改軟體的迭代過程。即程序員和用戶緊密聯繫，根據用戶反饋不斷添加功能或者修復缺陷。而缺陷和新功能往往並沒有清楚的界限，其實都是現有的軟體系統並沒有滿足用戶的需求。那麼，我們從缺陷修復開始研究，不斷試圖自動修復更難的缺陷，也許有一天就可以自動完成新功能的實現，最終實現自動開發軟體系統。同時，這條路線也保證了，如果最後的最高理想難以實現，中間產生的任何研究結果都是可以應用的。

缺陷自動修復/軟體自動化能實現嗎？

常常收到的一條反饋是：自動缺陷修復/軟體自動化這麼難，真的有可能最終做出來並達到良好效果的嗎？作為博士生/青年教師應該投入這一方向嗎？

對於這個問題我的首先回答是：做科研就不要懼怕困難的問題。有很多問題都是經過幾代人前仆後繼的努力才解決的。比如現在火爆的深度學習，就是起源於上世紀60年代的人工神經網路，經過五十多年的發展才有今天的應用。而數學物理學等傳統學科中研究了幾百年的困難問題比比皆是。事實上，這類困難的問題是正應該學術界研究的，因為無論你是否徹底解決了問題，只要有進展都可以寫成論文發表出來，而突破性進展也會被同行認可（參考陳景潤/張益唐）。另一方面，如果我們可以預期一個領域在短期內就能獲得突破，那麼很大概率這個領域已經不適合學術界研究了。因為工業界會有很多公司投入資本開展研究，而學術界的的力量往往是無法和大資本抗衡的。

當然，作為研究人員，對於一個長期研究的問題，確實需要有一些證據說服自己這個問題最終是可以做出來的。對於我們來說，這裡最大的不確定性在於軟體的需求其實幾乎不能被完整表達成規約的，那麼對於一個需求不是完全清楚的軟體系統，自動修復技術真的能修復缺陷嗎？為了解答這個疑問，我們做過一個受控實驗，讓程序員在不了解軟體需求的情況下去修復大型軟體系統中的50個隨機缺陷[11]。實驗結果表明，即使不了解軟體的功能，該程序員仍然修復了超過90%的缺陷，正確率也超過了90%。如果我們假設程序員在修復過程中經驗和策略都能夠通過某種方式轉變成演算法，那麼缺陷修復系統也至少有望達到了類似的修復率和正確率，其應用前景還是非常可觀的。同時，我們看到剩下不能被修復的缺陷和修復錯誤的缺陷也確實是由於程序員不夠了解軟體需求導致的，因此我們也在研究互動式的修復技術[12]，當修復系統對於某方面不夠清楚的時候，通過向用戶提問來獲取所需的信息。

[1] Yida Tao, Jindae Kim, Sunghun Kim, Chang Xu: Automatically generated patches as debugging aids: a human study. SIGSOFT FSE 2014: 64-74

[2] Caitlin Sadowski, Edward Aftandilian, Alex Eagle, Liam Miller-Cushon, Ciera Jaspan: Lessons from building static analysis tools at Google. Commun. ACM 61(4): 58-66 (2018)

[3] Caitlin Sadowski, Jeffrey van Gogh, Ciera Jaspan, Emma S?derberg, Collin Winter: Tricorder: Building a Program Analysis Ecosystem. ICSE 2015: 598-608

[4] Ripon K. Saha, Yingjun Lyu, Hiroaki Yoshida, Mukul R. Prasad: ELIXIR: effective object oriented program repair. ASE 2017: 648-659

[5] Ripon K. Saha, Yingjun Lyu, Wing Lam, Hiroaki Yoshida, Mukul R. Prasad: Bugs.jar: a large-scale, diverse dataset of real-world Java bugs. MSR 2018: 10-13

[6] Ben Mehne, Hiroaki Yoshida, Mukul R. Prasad, Koushik Sen, Divya Gopinath, Sarfraz Khurshid: Accelerating Search-Based Program Repair. ICST 2018: 227-238

[7] 徐家福. 軟體自動化. 計算機研究與發展, 1988 (11): 9-15

[8] R. C. Seacord, D. Plakosh, and G. A. Lewis, Modernizing legacy systems: software technologies, engineering processes, and business practices. Addison-Wesley Professional, 2003

[9] B. P. Lientz, E. B. Swanson, and G. E. Tompkins, 「Characteristics of application software maintenance,」Commun. ACM, vol. 21, no. 6, pp. 466–471, 1978.

[10] Britton et al. Quantify the time and cost saved using reversible debuggers. Cambridge report, 2013

[11] Jiajun Jiang, Yingfei Xiong: Can defects be fixed with weak test suites? An analysis of 50 defects from Defects4J. CoRR abs/1705.04149 (2017)

[12] Yingfei Xiong, Hansheng Zhang, Arnaud Hubaux, Steven She, Jie Wang, Krzysztof Czarnecki: Range Fixes: Interactive Error Resolution for Software Configuration. IEEE Trans. Software Eng. 41(6): 603-619 (2015)

推薦閱讀：

相关文章