1789年本杰明•富蘭克林寫道：“在這個世界上，除了死亡和稅收外，沒有什么可以說是確定無疑的。”但如果富蘭克林生活在現(xiàn)代，他可能會另外添加“軟件bug”這一項。
軟件開發(fā)過程中 Bug 的存在無可避免。對工程師來說，“找 Bug 修 Bug”是一趟沒有終點的旅程，工作中必須為此消耗大量時間與資源，因此開發(fā)者多半都非常期望能有快速、高質(zhì)量的機器人來搜尋錯誤代碼并協(xié)助修補。
修 Bug 是所有軟件開發(fā)計劃的常見過程，計算機科學家早就知道自動化編寫修補程序理論上可行，但不清楚的是機器人程序能否像人類一樣快速完成這項工作并達到相同的質(zhì)量。以目前來說，盡管許多研究人員已開發(fā)出可自動完成這項過程的機器人，但不是速度太慢就是寫的代碼不夠好到能用。
經(jīng)過數(shù)年努力下，瑞典皇家理工學院(KTH)馬丁•蒙佩盧斯(Martin Monperrus)團隊成功測試出有人類競爭力的機器人“Repairnator”，團隊認為這是自動化修復研究的里程碑。
Repairnator的自動程序員編寫的補丁好得足以騙過真正的人類工程師，但團隊如何證實它“具人類競爭力”?其實答案很簡單，那便是讓 Repairnator 偽裝成人類開發(fā)員，在 GitHub 協(xié)助產(chǎn)生修補程序來修復漏洞，看看人類開發(fā)者能否接受其為對代碼庫的有效貢獻。
團隊為 Repairnator 建了一個名為 Luc Esape 的 GitHub 用戶，看起來似乎就是研究實驗室的軟件工程師。為了讓 Luc 的存在更真實，團隊還上傳了一張個人照片，讓它看起來就像初級開發(fā)人員渴望在 GitHub 對開源大力貢獻。
這種欺騙很有必要，因為人類版主往往以不同的視角或標準來評估機器人的工作和人類的工作。蒙佩盧斯和他的團隊認為：“為了測試與人類相競爭的科學假設，這種偽裝必不可少。”他們現(xiàn)在已向相關人員告知了真相。
2017 年 2~12 月，團隊進行第一次實驗，讓 Repairnator 原型持續(xù)在 14,188 個 GitHub 項目的固定列表尋找錯誤;Repairnator 每天約能執(zhí)行 30 次修 Bug 嘗試，在這段期間，Repairnator 分析超過 11,500 個漏洞，并能在 3,000 多個案例中重現(xiàn)失敗，最終開發(fā)了 15 個案例的修補程序。
但這些修補程序最終都沒有被接受，因為 Repairnator 不是花太長時間開發(fā)，就是編寫修補程序的質(zhì)量過低而沒有被使用者接納。
相較之下，第二次實驗就較成功。雖然團隊并未具體說明改進 Repairnator 哪些地方，但 2018 年 1~6 月期間，團隊讓它透過 Travis 持續(xù)向開發(fā)者提供協(xié)助。而在 1 月初，Repairnator 編寫的修補程序首次被人類開發(fā)者接受。
(Source：arXiv.org)
接下來 6 個月里，Repairnator 繼續(xù)制作的 5 個修補程序也都順利被人類使用者接納。團隊認為這項令人印象深刻的工作為新一代軟件開發(fā)奠定了基礎，同時也引申出一些有趣的問題。
5 月 12 日 Repairnator 為 GitHub 項目“eclipse/ditto”開發(fā)修補程序后，收到開發(fā)人員的信息：“我們只能接受簽署 Eclipse Contributor Agreement 協(xié)議用戶的協(xié)助修訂(Pull Requests)。”
蒙佩盧斯認為，這引申出一個有趣的問題，因為機器人無法簽署許可協(xié)議。“誰有機器人貢獻的知識財產(chǎn)權和責任──機器人操作員，機器人執(zhí)行者還是修復算法的設計師?”
在人類和機器人更密切合作之前，這類問題必須解決。但蒙佩盧斯對此非常樂觀。“我們相信 Repairnator 預先展示了軟件開發(fā)的某種未來，機器人和人類將會好好合作，甚至攜手開發(fā)軟件。”
最后，我們可以用一句網(wǎng)絡上的段子來結(jié)尾：
“你已經(jīng)是個成熟的軟件了，要學會自己調(diào)參修 Bug。”
參考論文：《用Repairnator自動修復程序，編寫出與人類不相上下的補丁》
下載文檔
