聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

为什么一些好的开发工具会被束之高阁?

2021-06-15 14:47 浏览: 1194162 次 我要评论(0 条) 字号:

作者 | James Koppel
译者 | 盖磊
策划 | 万佳

过去九年,我一直致力于推动软件开发工具的发展。此前,所谓“编程工具”只是文件的格式化浏览和编辑窗口,也会提供多种查找方式。对此,我曾深入提出,如何使编程工具能推理一组更改背后的意图,进而不再局限于“查找并替换”。

时过境迁,编程人员对程序合成(program synthesis)等概念已耳熟能详,甚至已上手了某种验证工具。以高级开发工具研发为基础,市场上推出了多种得到广泛使用的产品,甚至 Facebook 已经企业内部部署了自动程序修复。

尽管编程工具广为部署,但学术界对工具的研究遥遥领先。我们常常会看到,即便是发表于二十多年前的学术论文所提出的理念,经实验性验证可将一些任务的开发效率提高数倍。但这些理念仅局限于学术界。

本文将浅析开发人员对高级工具的期望,以及所发生的退步。下面给出的三款工具出现于过去 30 年中,尽管我对它们的个人评价很高,但经我实测,均已无法正常运行。

1反射模型(Reflexion Model)

软件通常表示为组件。对于操作系统,组件就是文件系统、硬件接口和进程管理器等。如果一个项目需要实现更快地写入文件到磁盘,那么经验丰富的工程师能定位到确切的代码位置,而新手则面对一大堆的源文件会无从下手。

1995 年,就读于华盛顿大学的年轻研究生 Gail C. Murphy 提出了一种理解代码库的新方法,称为“反射模型”(reflexion model)。具体描述为:

首先,对各组件及相互间交互做出大体上的假设。

进而查看源代码,记录下对组件与源代码对应关系的认识。

之后通过运行工具,获得文件间的实际关联(例如,类的继承关系、对象图的调用关系等),并与前期假设做对比。

最后,基于实践认知,修正前期假设,不断充实对模型的认知,使认知模型逐渐逼近事实。

大约同时,微软的一个研究小组也在开展一项实验。该实验的目的是验证是否能改造 Excel 代码库,从中抽取出部分高层组件。这需要对代码库具有相当深入的理解,考虑到该小组与 Execl 开发团队完全没有交集,实现此事并非易事。研究小组中有人看了 Gail 关于“反射模型”的宣讲,深以为然。

他用一天的时间就建立了首个 Excel 反射模型,通过日渐熟悉代码而不断修正模型。在随后的四周时间中,他对代码的理解达到了先前预估需两年时间才能企及的程度。

时至今日,Gail 发布的 RMTool 已无法从因特网公开获取,其所基于的 AT&T C++ 分析工具 Ciao 同样也从因特网下线。尽管有人随后使用 Java 重写并实现为 JRMTool,但其仅能用于 Eclipse 的早期版本,完全不适用于当前的 API 了。JRMTool 采用 Java 1.4 编写,当前的 Java 发行版在语法上做了彻底更改。因此,我完全放弃了尝试获取代码并编译运行的想法。

时至 2021 年,软件工程依然无法超越 1995 年的水平。

2WhyLine

时间又过了十年,卡内基梅隆大学人机接口(HCI)研究所的 Amy Ko 思考着另一个问题。调试过程就像是当侦探,为什么程序不在完成取数(fetch)后更新缓存?其中负数起了什么作用?为什么解答此类问题如此费劲?

上述想法促成 Amy 设计了一种称为 WhyLine 的工具。WhyLine 提供交互式调试界面,用户可提出“为什么某事会发生?”之类的问题。WhyLine 在图像编程工具 Alice 中实现了一个原型。Alice 是 CMU 实现的图形化编程工具,即便是儿童都可生成三维动画,令人印象深刻。


Amy 基于原型的成功,又历经数年努力,建立了针对 Java 语言实现该功能的技术。


他们开展的一项研究,要求 20 位程序员去修复存在于 ArgoUML 中的两个错误,这是一个 15 万行 Java 代码的程序。一半参试程序员使用 Java WhyLine。实验结果表明,相比未使用 WhyLine 的程序员,使用 WhyLine 程序员的成功率提高了四倍,工作速度提高了两倍。

我在几年前曾试图使用现代 Java 字节码平台去运行 JavaWhyLine,但是程序崩溃了。

3MatchMaker

2008 年,我的导师 Armando Solar-Lezama 加入 MIT,一手恢复了程序合成(program synthesis)领域的研究。他过去主要关注小型系统中的复杂问题,包括优化物理仿真和位交错(bit-twiddling),目前正转向解决大型系统中的简单问题。

大多数的编程工作其实是在编写“胶水代码”,只需厘清如何组合使用大量的标准组件库。要明确如何使用复杂框架执行特定操作,可能需要花数周时间深入阅读文档。程序合成技术是否能在其中发挥作用?这正是来自哈萨克的天才 Kuat Yessenov 研究去解决的问题。

使用胶水代码的通常规则,是弄清楚需使用的具体类和方法。有时程序员能猜测得八九不离十。例如,Android 中使用 Container 类的addView方法即可在屏幕上部署小组件。但更多情况下是不容易猜到的。例如,在编写一个能高亮显示语法的 Eclipse 插件时,需要链接使用四个类,关联TextEditor对象与RuleBasedScanner,示例代码如下:

class UserConfiguration extends SourceViewerConfiguration {  IPresentationReconciler getPresentationReconciler() {    PresentationReconciler reconciler = new PresentationReconciler();    RuleBasedScanner userScanner = new UserScanner();    DefaultDamagerRepairer dr = new     DefaultDamagerRepairer(userScanner);    reconciler.setRepairer(dr, DEFAULT_CONTENT_TYPE);    reconciler.setDamager(dr, DEFAULT_CONTENT_TYPE);    return reconciler;  }}
class UserEditor extends AbstractTextEditor { UserEditor() { userConfiguration = new UserConfiguration(); setSourceViewerConfiguration(userConfiguration); }}class UserScanner extends RuleBasedScanner {...}

如果能推断出某个功能的两个端点,哪些类使用了它,以及哪些类提供它,那么中间过程就可交给计算机去操心。当然,还有其他一些程序能实现这样的功能。通过运行这些程序并做分析跟踪,就能找到作为指针引用链负责“链接”两个类的代码。这样,程序引用就能具体归结到确切实现功能的代码。基于这一理念,MatchMarker 应运而生!


在一项研究中,要求 8 位程序员去构建一个基本的 Eclipse 语法高亮显示功能,高亮显示一种新语言中的两个关键字。该研究为半数参试程序员提供了 MatchMaker 及其基本教程。该教程中的确给出了如何去执行操作,但是其中内容繁杂,并没有多大帮助。对照组历经波折,平均 100 分钟完成。而使用 MatchMaker 的一组很快就摸清了门路,平均只用了 50 分钟。鉴于具有 5 年经验的 Eclipse 专家耗时 16 分钟,这一结果相当不错。

事实上,我非常了解 Matchmaker,因为我读研的第一个月就被安排参与推进该项目。我很喜欢该项目,推动了项目的扩展并支持 Android。但该项目也退步了。几年前,我的导师引进了一名暑期实习生去开发 MatchMaker。但他很快就碰上麻烦,MatchMaker 无法在 Java 8 上运行。

4三个观点

第一个观点,我们所使用的工具在很大程度上取决于一些关键个体的选择。尽管 Mylyn 成为最受欢迎的 Eclipse 插件之一,“反射模型”这一理念仍然籍籍无名。这完全可归因为模型的提出者 Gail C. Murphy 决心投身学术界,而她的学生、Mylyn 的创建者 Mik Kersten,则选择了加入工业界。

编程工具并非一个可将进步视为“某个理念的时代已经到来”的领域。这只会发生在类似理念有很多人研究的情况下。即便该理念并未被某个人所采纳,那么几年后也得到其他人的采纳。而这种竞争在编程工具领域是非常罕见的。

举个例子,一位著名的教授学术休假去创立了一家网站构建工具公司。我曾问他,如果他的理念能打败所有前期同类工具,那么为什么以前没有人做过?他的回答大体意思是,“只有我才能打造此类工具所需的技术”。

第二个观点,当前编程工具的构建方式是存在问题的。在其他计算机科学领域,科研人员和业界从业人员之间应该不存在如此巨大的鸿沟。我此前曾提出,构建工具的难度更多地取决于编程语言的复杂性(编程语言的复杂性,由 C++ 即可见一斑),而非取决于研究理念。在变革性理念出现之前,如果构建工具的销售量不足以支撑其巨大的固定成本,那么不可能推出任何新的工具。这正是我博士研究致力于简化工具构建的初心所在,也是我对那些不够先进但是免费工具的泛滥痛心疾首的原因。这些工具导致市场低迷,工具开发商难以收回成本。

http://www.pathsensitive.com/2018/09/my-interview-with-future-of-coding-on.html?fileGuid=Rj6VWG3wggRcKW66

第三个观点是,作为开发人员,我们应该对工具提出更多的要求。如果你曾考虑过构建一种开发者工具,那么有大量很好的工作可以借鉴。如果你渴求更好的工具,就必须报以期待。

原文链接:

http://www.pathsensitive.com/2021/03/developer-tools-can-be-magic-instead.html?m=1&fileGuid=Rj6VWG3wggRcKW66

今日好文推荐

维护开源项目太难了,Redis之父:只做自己想做的

误泄露公司代码、疫情期间被裁,一个“菜鸟”程序员的生存日记

小小技术“障眼法”,思科、微软和联想被骗超350万美元

我们4个人做了一款年入百万美元的邮件客户端

税务网站上线首日就宕机,财政部长怒喷印度第二大IT公司

腾讯试点强制6点下班;滴滴递交上市申请;某Top级互联网公司被攻陷,超11亿条信息外泄 | Q资讯


InfoQ 写作平台欢迎所有热爱技术、热爱创作、热爱分享的内容创作者入驻!

还有更多超值活动等你来!

扫描下方二维码

填写申请,成为作者

开启你的创作之路吧~

点个在看少个 bug 



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复