原文地址：www.pathsensitive.com/2021/03/dev…

原文作者：www.jameskoppel.com/

发布时间：2021年3月28日

9年前，我开始研究高级开发工具。当我开始的时候，"编程工具 "意味着文件格式查看器、编辑器，也许还有grep的变种。我提到一个深层次的问题，比如推断一组变化的基本意图，并得到关于它与find-and-replace相比如何的问题。

时代已经变了。当我遇到1个听说过程序综合，甚至尝试过验证工具的程序员时，不再感到震惊。现在有几1种基于先进工具研究的流行产品，人工智能的进步普遍改变了人们的期望。有1家公司，Facebook，甚至已经在内部部署了自动程序修复。

尽管这样，工具研究仍然比部署的东西领先一光年。读到一篇20年前的论文，其中的工具实证显示可以让程序员在一项任务上快4倍，而基础理念还锁定在学术界，这一点也不稀奇。

我想让大家感受一下对先进工具的期待--以及我们正在倒退的方式。现在我将介绍过去30年中我最喜欢的3个工具，这些工具我都尝试过使用，目前都没有运行。

反射模型

我们经常从组件的角度来看待软件。对于一个操作系统来说，可能是：文件系统、硬件接口、进程管理器。一个有经验的工程师在项目中被要求让某些文件更快地写入磁盘，他会清楚地知道代码中的位置；而一个新人则会看到一个无定形的blob的源文件。

1995年，作为华盛顿大学的年轻研究生，Gail C. Murphy想出了一种新的学习代码库的方法，叫做反射模型。

首先，你提出一个粗略的假设，你认为这些组件是什么，它们是如何相互作用的。

然后，你检查一下代码，写下你认为每个文件如何与组件对应。

现在，工具运行，并计算出文件的实际连通性（例如：类继承、调用图）。你将它与你的假设进行比较。

有了新的证据，你就会完善你的假设，让你的心理模型越来越详细，越来越符合实际情况。

大约在这个时候，微软的一个小组正在做一个实验，看看他们是否能重新设计Excel代码库，提取出一些高级组件。他们需要对代码库有相当强的理解，但得到代码库并不那么容易，因为他们是不同的团队，在不同的大楼里。他们中的一个人看到了Gail关于反射模型的演讲，很喜欢。

在一天之内，他为Excel创建了他的第一个反射模型的切面。然后，他花了四个星期的时间来完善它，因为他对代码更加熟悉了。这样一来，他的理解能力达到了他估计要花两年时间才能理解的程度。

如今，Gail最初的RMTool已经从互联网上消失了。它所基于的AT&T公司的C++分析工具Ciao更是脱离了互联网。后来他们又写了一个Java版本，jRMTool，但它只是针对老版本的Eclipse，API完全不同。代码是用Java 1.4写的，甚至连语法都不正确了。我很快就放弃了让它运行的尝试。

2021年的软件工程。还在追赶1995年的步伐

WhyLine

大约10年后，在卡耐基梅隆的人机交互研究所，Amy Ko在思考另一个问题。调试就像一个侦探。为什么程序做完取数后不更新缓存？负数在这里做什么？为什么回答这些问题这么费劲？

Amy有一个想法，她想做一个叫做Whyline的工具，在这个工具中，你可以在一个交互式的调试器中问一些问题，比如 "为什么会发生_____？"。她为爱丽丝做了一个原型，这是CMU的图形化编程工具，可以让孩子们制作3D动画。人们对此印象深刻。

在成功的鼓舞下，现在已经成为教授的Amy又花了几年时间努力工作，建立起了可以在Java中实现这一功能的技术。

他们进行了一项研究。20个程序员被要求修复ArgoUML中的两个错误，这是一个15万行的Java程序。其中一半的程序员得到了一份Java WhyLine。有WhyLine的程序员比没有WhyLine的程序员成功率高4倍，工作速度也快两倍。

几年前，我尝试使用Java WhyLine。当面对现代Java字节码时，它崩溃了。

匹配器

2008年，我的导师Armando Solar-Lezama刚到麻省理工学院，就一手振兴了程序综合领域。他主要专注于小系统中的复杂问题，比如优化物理模拟和位机。现在他想解决大系统中的简单问题。编程的大部分内容都是在写 "胶水代码"，把一个大型的标准组件库，想办法把它们栓在一起。要想知道如何在一个复杂的框架中做某事，可能要花上几周的时间去挖掘文档。综合技术能不能帮上忙？哈萨克天才Kuat Yessenov的任务就是想办法。

胶水代码往往是一个游戏，要弄清楚使用什么类和方法。有时并不难猜：比如在Android中，你把一个widget放到屏幕上的方法，就是用容器的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 {...}

他推理说，如果你能弄清楚一个功能的两个端点，什么类使用它，什么类提供它，那么你就可以要求计算机弄清楚中间的东西。还有其他程序可以实现你要找的功能。通过运行它们并分析痕迹，你可以找到负责 "连接 "这两个类的代码（作为指针引用链）。然后，你可以将引用程序归结为具体实现这些功能的代码--瞧，一个教程！MatchMaker工具应运而生。MatchMaker工具就诞生了。

在研究中，8名程序员被要求为Eclipse构建一个简单的语法高亮器，高亮一个新语言中的两个关键词。其中一半人得到了MatchMaker和一个简短的使用教程。是的，有多个教程介绍如何做到这一点，但它们包含的信息太多，而且没有帮助。对照组则一筹莫展，平均时间为100分钟。MatchMaker用户很快就知道了他们要找什么，只花了50分钟。考虑到一个有5年经验的Eclipse专家花了整整16分钟，这还不算太糟。

我实际上确实使用了Matchmaker，因为在我读研究生的第一个月，我被要求参与其后续产品的开发。相当不错；我很想看到它充实起来，并使之适用于Android。唉，我们正在往回滑。几年前，我的导师雇佣了一个暑期实习生来开发MatchMaker。他立刻遇到了一个障碍：它不能在Java 8上工作。

教训

第一个教训是，我们使用的工具在很大程度上是由杰出人士的选择所决定的。Reflexion Models默默无闻，而Mylyn却跻身于最流行的Eclipse插件之列，原因很简单，因为Reflexion Models的创造者Gail C. Murphy决定投身学术界，而她的学生Mylyn的创造者Mik Kersten则投身于工业界。

编程工具并不是一个领域，在这个领域里，进步是 "一个时代已经到来的想法"。当有很多人在研究类似的想法时，就会出现这种情况；如果一个人的想法没有被采用，那么几年后就会有其他人采用。在编程工具中，这种竞争是罕见的。举个例子来说明。一个著名的教授休假去开了一家公司 建立一个制作网站的工具。我问他，如果他的想法要打败以前所有的这类工具，为什么以前没有人做。他的回答是："因为它需要的技术，只有我才能打造。"

第二个教训是，我们构建编程工具的方式有问题。计算机科学的其他领域似乎没有研究人员和实践者的成就之间有如此巨大的裂痕。我以前曾认为，这是因为构建工具的难度更多地取决于编程语言的复杂程度（编程语言极其复杂，看看C++就知道了），而不是思想，在这种情况改变之前，没有足够的销售量来支付构建工具的巨大固定成本，任何工具都不可能出现。这就是为什么我的博士一直致力于让工具更容易构建的原因。这也是为什么我对免费但并不先进的工具泛滥感到部分沮丧的原因：它甩开了市场的底线，让这些固定成本更难偿还。

但第三条经验是，作为开发者，我们可以从我们的工具中要求更多。如果你曾经想过构建一个开发者工具，你有那么多令人印象深刻的作品可以借鉴。如果你渴望更好的工具，这就是你要期待的。

来源

• 软件反射模型。缩小源模型和高级模型之间的差距
• 用反射模型进行再造。一个案例研究。
• 设计Whyline。设计Whyline：一个用于询问程序行为问题的调试界面。
• 使用Java Whyline寻找程序输出的原因。
• 面向对象的框架的数据驱动合成技术