1789年本杰明•富蘭克林寫道：“在這個世界上，除了死亡和稅收外，沒有什么可以說是確定無疑的。”但如果富蘭克林生活在現(xiàn)代，他可能會另外添加“軟件bug”這一項。

軟件開發(fā)過程中 Bug 的存在無可避免。對工程師來說，“找 Bug 修 Bug”是一趟沒有終點的旅程，工作中必須為此消耗大量時間與資源，因此開發(fā)者多半都非常期望能有快速、高質(zhì)量的機器人來搜尋錯誤代碼并協(xié)助修補。

修 Bug 是所有軟件開發(fā)計劃的常見過程，計算機科學(xué)家早就知道自動化編寫修補程序理論上可行，但不清楚的是機器人程序能否像人類一樣快速完成這項工作并達(dá)到相同的質(zhì)量。以目前來說，盡管許多研究人員已開發(fā)出可自動完成這項過程的機器人，但不是速度太慢就是寫的代碼不夠好到能用。

經(jīng)過數(shù)年努力下，瑞典皇家理工學(xué)院(KTH)馬丁•蒙佩盧斯(Martin Monperrus)團隊成功測試出有人類競爭力的機器人“Repairnator”，團隊認(rèn)為這是自動化修復(fù)研究的里程碑。

Repairnator的自動程序員編寫的補丁好得足以騙過真正的人類工程師，但團隊如何證實它“具人類競爭力”?其實答案很簡單，那便是讓 Repairnator 偽裝成人類開發(fā)員，在 GitHub 協(xié)助產(chǎn)生修補程序來修復(fù)漏洞，看看人類開發(fā)者能否接受其為對代碼庫的有效貢獻(xiàn)。

團隊為 Repairnator 建了一個名為 Luc Esape 的 GitHub 用戶，看起來似乎就是研究實驗室的軟件工程師。為了讓 Luc 的存在更真實，團隊還上傳了一張個人照片，讓它看起來就像初級開發(fā)人員渴望在 GitHub 對開源大力貢獻(xiàn)。

這種欺騙很有必要，因為人類版主往往以不同的視角或標(biāo)準(zhǔn)來評估機器人的工作和人類的工作。蒙佩盧斯和他的團隊認(rèn)為：“為了測試與人類相競爭的科學(xué)假設(shè)，這種偽裝必不可少。”他們現(xiàn)在已向相關(guā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 個修補程序也都順利被人類使用者接納。團隊認(rèn)為這項令人印象深刻的工作為新一代軟件開發(fā)奠定了基礎(chǔ)，同時也引申出一些有趣的問題。

5 月 12 日 Repairnator 為 GitHub 項目“eclipse/ditto”開發(fā)修補程序后，收到開發(fā)人員的信息：“我們只能接受簽署 Eclipse Contributor Agreement 協(xié)議用戶的協(xié)助修訂(Pull Requests)。”

蒙佩盧斯認(rèn)為，這引申出一個有趣的問題，因為機器人無法簽署許可協(xié)議。“誰有機器人貢獻(xiàn)的知識財產(chǎn)權(quán)和責(zé)任──機器人操作員，機器人執(zhí)行者還是修復(fù)算法的設(shè)計師?”

在人類和機器人更密切合作之前，這類問題必須解決。但蒙佩盧斯對此非常樂觀。“我們相信 Repairnator 預(yù)先展示了軟件開發(fā)的某種未來，機器人和人類將會好好合作，甚至攜手開發(fā)軟件。”

最后，我們可以用一句網(wǎng)絡(luò)上的段子來結(jié)尾：

“你已經(jīng)是個成熟的軟件了，要學(xué)會自己調(diào)參修 Bug。”

參考論文：《用Repairnator自動修復(fù)程序，編寫出與人類不相上下的補丁》