1789年本杰明•富兰克林写道:“在这个世界上,除了死亡和税收外,没有什么可以说是确定无疑的。”但如果富兰克林生活在现代,他可能会另外添加“软件bug”这一项。
软件开发过程中 Bug 的存在无可避免。对工程师来说,“找 Bug 修 Bug”是一趟没有终点的旅程,工作中必须为此消耗大量时间与资源,因此开发者多半都非常期望能有快速、高质量的机器人来搜寻错误代码并协助修补。
修 Bug 是所有软件开发计划的常见过程,计算机科学家早就知道自动化编写修补程序理论上可行,但不清楚的是机器人程序能否像人类一样快速完成这项工作并达到相同的质量。以目前来说,尽管许多研究人员已开发出可自动完成这项过程的机器人,但不是速度太慢就是写的代码不够好到能用。
经过数年努力下,瑞典皇家理工学院(KTH)马丁•蒙佩卢斯(Martin Monperrus)团队成功测试出有人类竞争力的机器人“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)。”
蒙佩卢斯认为,这引申出一个有趣的问题,因为机器人无法签署许可协议。“谁有机器人贡献的知识财产权和责任──机器人操作员,机器人执行者还是修复算法的设计师?”
在人类和机器人更密切合作之前,这类问题必须解决。但蒙佩卢斯对此非常乐观。“我们相信 Repairnator 预先展示了软件开发的某种未来,机器人和人类将会好好合作,甚至携手开发软件。”
最后,我们可以用一句网络上的段子来结尾:
“你已经是个成熟的软件了,要学会自己调参修 Bug。”
参考论文:《用Repairnator自动修复程序,编写出与人类不相上下的补丁》
本文综合自云头条、Technews、IT程序猿、开源中国报道
关注最前沿的电子设计资讯,请关注“电子工程专辑微信公众号”
- 这个快点实现吧,让我在软件排错上少费脑力。