工程師小幫手?瑞典團隊開發出有人類修 Bug 水準的機器人

作者 | 發布日期 2018 年 10 月 27 日 23:35 | 分類 軟體、系統 follow us in feedly

軟體開發過程中 Bug 的存在無可避免。對工程師來說,「找 Bug 修 Bug」是一趟沒有終點的旅程,工作中必須為此消耗大量時間與資源,因此開發者多半都非常期望能有快速、高質量的機器人來搜尋錯誤代碼並協助修補。



修 Bug 是所有軟體開發計畫的常見過程,電腦科學家早就知道自動化編寫修補程式理論上可行,但不清楚的是機器人程式能否像人類一樣快速完成這項工作並達到相同的品質。以目前來說,儘管許多研究人員已開發出可自動完成這項過程的機器人,但不是速度太慢就是寫的代碼不夠好到能用。

經過數年努力下,瑞典皇家理工學院(KTH)團隊成功測試出有人類競爭力的機器人「Repairnator」,團隊認為這是自動化修復研究的里程碑。

但團隊如何證實 Repairnator「具人類競爭力」?其實答案很簡單,那便是讓 Repairnator 偽裝成人類開發員,在 GitHub 協助產生修補程式來修復漏洞,看看人類開發者能否接受其為對代碼庫的有效貢獻。

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

2017 年 2~12 月,團隊進行第一次實驗,讓 Repairnator 原型持續在 14,188 個 GitHub 項目的固定列表尋找錯誤;Repairnator 每天約能執行 30 次修 Bug 嘗試,在這段期間,Repairnator 分析超過 11,500 個漏洞,並能在 3,000 多個案例中重現失敗,最終開發了 15 個案例的修補程式。

但這些修補程式最終都沒有被接受,因為 Repairnator 不是花太長時間開發,就是編寫修補程式的品質過低而沒有被使用者接納。

相較之下,第二次實驗就較成功。雖然團隊並未具體說明改進 Repairnator 哪些地方,但 2018 年 1~6 月期間,團隊讓它透過 Travis 持續向開發者提供協助。而在 1 月初,Repairnator 編寫的修補程式首次被人類開發者接受。

(Source:arXiv.org

接下來 6 個月裡,Repairnator 繼續製作的 5 個修補程式也都順利被人類使用者接納。團隊認為這項令人印象深刻的工作為新一代軟體開發奠定了基礎,同時也引申出一些有趣的問題。

5 月 12 日 Repairnator 為 GitHub 項目「eclipse/ditto」開發修補程式後,收到開發人員的訊息:「我們只能接受簽署 Eclipse Contributor Agreement 協議用戶的協助修訂(Pull Requests)。」

開發者之一的 Martin Monperrus 認為,這引申出一個有趣的問題,因為機器人無法簽署許可協議。「誰有機器人貢獻的知識財產權和責任──機器人操作員,機器人執行者還是修復演算法的設計師?」

在人類和機器人更密切合作之前,這類問題必須解決。但 Monperrus 對此非常樂觀。「我們相信 Repairnator 預先展示了軟體開發的某種未來,機器人和人類將會好好合作,甚至攜手開發軟體。」

*為了讓評估者判斷能公平,隱瞞 Repairnator 身分是必須的,實驗結束後,Monperrus 也告知涉及相關內容的開發者。

(首圖來源:shutterstock)