银弹的希望

现在，让我们来讨论一下当今可能作为潜在银弹的最先进的技术进步。它们各自针对什么样的问题？它们是属于必要问题，或者依然是解决我们剩下的次要困难？它们是提供了创新，还是仅仅是增量改进？

Ada和其他高级编程语言。近来，最被吹捧的开发进展之一是编程语言Ada，一种20世纪80年代的高级语言。Ada实际上不仅仅反映了语言概念上的突破性进展，而且蕴涵了鼓励现代设计和模块化概念运用的重要特性。由于Ada采用的是抽象数据类型、层次结构的模块化理念，所以Ada理念可能比语言本身更加先进。Ada使用设计来承载需求，作为这一过程的自然产物，它可能过于丰富了。不过，这并不是致命的，因为它的词汇子集可以解决学习问题，硬件的进展能提供更高的MIPS(每秒百万指令集)，减少编译的成本。软件系统结构化的先进理念实际上非常好地利用了MIPS上的进展。20世纪60年代，曾在内存和循环成本上广受谴责的操作系统，如今已被证明是一种能使用某些MIPS和廉价内存的非常优秀的系统。

然而，Ada仍然不是消灭软件生产率怪兽的银弹。毕竟，它只是另一种高级语言，这类语言最大的回报来自出现时的冲击，它通过使用更加抽象的语句来开发，降低了机器的次要复杂度。一旦这些难题被解决，就只剩下非常少的问题了，解决剩余部分的获益必然也要少一些。

我预言，在以后的十年中，当Ada的效率被大家评估认可时，它会产生相当大的变化，但并不是因为任何特别的语言特性，不是由于这些语言特性被合并在一起，也不是因为Ada开发环境会不断发展进步。Ada的最大贡献在于编程人员培训方式的转变，即对开发人员需要进行现代软件设计技术培训。

面向对象编程。软件专业的一些学生坚持面向对象编程是当今若干新潮技术中最富有希望的。^[3]我也是其中之一。达特茅斯的Mark Sherman提出，必须仔细地区别两个不同的概念：抽象数据类型和层次化类型，后者也被称为类(class)。抽象数据类型的概念是指对象类型应该通过一个名称、一系列合适的值和操作来定义，而不是理应被隐藏的存储结构。抽象数据类型的例子是Ada包(以及私有类型)和Modula的模块。

层次化类型，如Simula-67的类，是允许通用接口的定义可以被后续子类型精化的。这两个概念是互不相干的—— 可以只有层次化，没有数据隐藏；也可能是只有数据隐藏，而没有层次化。两种概念都体现了软件开发领域的进步。

它们的出现都消除了开发过程中的非本质困难，允许设计人员表达自己设计的内在特性，而不需要表达大量句法上的内容，这些内容并没有添加新的信息。对于抽象数据类型和层次化类型，它们都是解决了高级别的次要困难并允许采用较高层次的表现形式来表达设计。

不过，这些提高仅仅能消除所有设计表达上的次要困难。软件的内在问题是设计的复杂度，上述方法并没有对它有任何的促进。除非我们现在的编程语言中，不必要的低层次类型说明占据了软件产品设计的90％，面向对象编程才能带来数量级上的提高。对面向对象编程这颗“银弹”，我深表怀疑。

人工智能。很多人期望人工智能上的进展可以给软件生产率和质量带来数量级上的增长，^[4]但我不这样认为。究其原因，我们必须剖析“人工智能”意味着什么，以及它是如何应用的。

Parnas澄清了术语上的混乱：

现在有两种差异非常大的AI定义被广泛使用。AI-1：使用计算机来解决以前只能通过人类智慧解决的问题。AI-2：使用启发式或基于规则的特定编程技术。在这种方法中，对人类专家进行了研究，判断他们解决方法的启发性思维或者经验法则……程序被设计成以人类解决问题的方式来运作。

第一种定义的意义容易发生变化……今天可能适合AI-1定义的程序，一旦我们了解了它的运行方式，理解了问题，就不再认为它是人工智能……遗憾的是，我无法识别这个领域的特定知识体系……绝大多数工作是针对问题域的，我们需要一些抽象或者创造性来解决上述问题。^[5]

我完全同意这种批评意见。语音识别技术与图像识别技术的共同点非常少，它们又都与专家系统中应用的技术不同。例如，我觉得很难去发现图像识别技术能给编程开发实践带来什么样的差异。同样，语音识别也差不多—— 软件开发上的困难是决定说什么，而不是如何说。表达的简化仅仅能提供少量的促进作用。

至于AI-2专家系统技术，应该用专门的章节来讨论。

专家系统。人工智能领域最先进的、被最广范使用的部分，是开发专家系统的技术。很多软件科学家正非常努力地工作着，想把这种技术应用在软件的开发环境中。^[6]那么它的概念是什么，前景如何？

专家系统是包含归纳推论引擎和规则基础的程序，它接收输入数据和假设条件，通过从基础规则推导逻辑结果，提出结论和建议，向用户展示前因后果，并解释最终的结果。推论引擎除了处理推理逻辑以外，通常还包括复杂逻辑或者概率数据和规则。

对于解决相同的问题，这种系统明显比传统的程序算法要先进很多。

●   推论引擎技术的开发独立于应用程序，因此可以有多种用途。在该引擎上付出较大的力气是很合理的。实际上，这种引擎技术非常先进；

●   基于应用的、可变更的部分，在基础规则中以一种统一的风格编码，并且为规则基础的开发、更改、测试和文档化提供了若干工具。这实际上对一些应用程序本身的复杂度进行了系统化。

Edward Feigenbaum指出，这种系统的能力不是来自某种前所未有的推导机制，而是来自非常丰富的知识积累基础，这一基础更加精确地反映了现实世界。我认为这种技术提供的最重要进步是具体应用的复杂度与程序本身相分离。

如何把它应用在软件开发工作中呢？可以通过很多途径：建议接口规则、制定测试策略、记录各种bug产生的频率和提供优化建议，等等。

例如，考虑一个虚构的测试顾问系统。在最根本的级别，诊断专家系统和飞行员的检查列表很相似，对困难可能的成因提供基本建议。建立基础规则时，可以依据更多的复杂问题征兆报告，从而使这些建议更加精确。可以想象，一种调试辅助程序起初提供的是一般化建议，随着基础规则包括越来越多的系统结构信息，它产生的推测和推荐的测试也越来越准确。这种类型的专家系统可能与传统系统彻底分离，系统中的规则基础可能与相应的软件产品具有相同的层次模块化结构，因此当对产品进行模块化修改时，诊断规则也能相应地进行模块化修改。

产生诊断规则也是在为模块和系统编制测试用例集时必须完成的任务。如果它以一种适当通用的方式来完成，对规则采用一致的结构，拥有一个良好可用的推测引擎，事实上它就可以减少测试用例设计的总体工作量，并帮助整个软件生命周期的维护和修改测试。同样，我们可以推测其他的顾问专家系统—— 可能是它们中的某一些，或者是较简单的系统—— 能够用在软件开发的其他部分。

在较早实现的用于软件开发的专家顾问系统中存在着很多困难。在我们假设的例子中，一个关键的问题是寻找一种简单的方法，能从软件结构的技术说明中，自动或者半自动地产生诊断规则。另外，更加重要也是更加困难的任务是：寻觅能够清晰表达，深刻理解来龙去脉，前因后果事情的自我分析专家；开发有效的技术—— 抽取专家们所了解的知识，把它们精炼成基础规则。这项工作的工作量是知识获取工作量的两倍。构建专家系统的必要前提条件是拥有专家。

专家系统最强有力的贡献是给缺乏经验的开发人员提供服务，用最优秀的开发者的经验和知识积累为他们提供指导，这是非常大的贡献。最优秀和一般的软件工程实践之间的差距是非常大的，可能比其他工程领域中的差距都要大，一种传播优秀实践的工具特别重要。

“自动”编程。近四十年，人们一直在预言和编写有关“自动编程”的文字，从问题的一段陈述说明自动产生解决问题的程序。现在，仍有一些人期望这样的技术能够成为下一个突破点。^[7]

Parnas暗示这是一个用于魔咒的术语，本身的语义是不完整的，并断言：

一句话，自动编程总是成为一种热情，使用现在并不可用的更高级语言编程的热情。^[8]

他指出，大多数情况下所给出的技术说明本质上是问题的解决方法，而不是问题自身。

可以找到一些例外情况。例如，数据发生器的开发技术就非常实用，并经常地用于排序程序中。一些微积分方程系统也允许直接描述问题。系统评估若干参数，从问题解决方案库中进行选择，生成合适的程序。

这样的应用具有非常良好的特性：

●   问题通过相对较少的参数迅速地描述特征；

●   存在很多已知的解决方案，提供了可供选择的库；

●   在给定问题参数的前提下，大量广泛的分析为选择具体的解决技术提供了清晰的规则。

具有上述简洁属性的系统是一个例外，除此之外很难看到该方法能普及到更广泛的寻常软件系统，甚至难以想象这种突破如何能够进行推广。

图形化编程。在软件工程的博士论文中，一个很受欢迎的主题是图形化或可视化编程，计算机图形在软件设计上的应用。^[9]这种方法的推测部分来自VLSI芯片设计的类比，计算机图形化在该设计中扮演了高生产力的角色。部分源于—— 人们将流程图作为一种理想的设计介质，并为构建它们提供了很多功能强大的实用程序—— 这证实了图形化的可行性。

不过，上述方法中至今还没有出现任何令人信服，更不用说令人激动的进步。我确信将来也不会出现。

首先，如同我先前所提出的，流程图是一种非常差劲的软件结构表达方法。^[10]实际上，它最好被视为是Burks,von Neumann和Gold stine试图为他们所设计的计算机提供的一种当时迫切需要的高级控制语言。如今的流程图已经变得复杂了，一张图有若干页，有很多连接结点，这种表现形式实在令人同情。流程图已经被证明是完全不必要的设计工具—— 程序员是在开发之后，而不是之前绘制描述程序的流程图。

其次，现在的屏幕非常小，就像素级别，无法同时表现软件图形的所有正式、详细的范围和细节。现在所谓 “类似桌面”的工作站实际上像是“飞机坐舱座椅”。在飞机上任何坐在两个肥胖乘客之间，反复挪动一大兜文件的人都会意识到这中间的差别—— 每次只能看到很少的内容。真正的桌面提供了很多文件的总览，让大家可以随意地使用它们。此外，当人们的创造力一阵阵地涌现时，开发人员大多数都会舍弃工作台，使用空间更为广阔的地板。要使我们面对的工作空间满足软件开发工作的需要，硬件技术必须进一步发展。

更加基本的是，如同我们上面所讨论的，软件非常难以可视化。即使用图形表达出了流程图、变量范围嵌套情况、变量交叉引用、数据流和层次化数据结构等等，也只是表达了某个方面，就像盲人摸象一样。如果我们把很多相关的视图叠加在所产生的图形上，那么很难再抽取出全局的总体视图。对VLSI芯片设计方法的类推是一种误导—— 芯片设计是对两维对象的层次设计，几何特性反映了它的本质特性，而软件系统不是这样。

程序验证。现代编程的许多工作是测试和修复bug。是否有可能出现银弹，能够在系统设计阶段、源代码阶段就消除bug？是否可以在大量工作被投入实现和测试之前，通过采用证实设计正确性的“深奥”策略，彻底提高软件的生产率和产品的可靠性？

我并不认为这里能找到魔法。程序验证的确是很先进的概念，它对安全操作系统内核等这类应用是非常重要的。不过，这项技术并不能保证节约劳动力。验证要求如此多的工作量，最终却只有少量的程序能够真正得到验证。

程序验证并不意味着零缺陷的程序。这里也没有什么魔术，数学验证仍然可能是有错误的。因此，尽管验证可能减少程序测试的工作量，却不能省略程序测试。

更严肃地说，即使完美的程序验证也只能建立满足技术说明的程序。这时，软件工作中最困难的部分已经接近完成，形成了完整和一致的说明。开发程序的一些必要工作实际上已经变成了对技术规格说明进行的测试。

环境和工具。向更好的编程开发环境研究中投入，我们可以期待得到多少回报呢？人的本能反应是首先着手解决高回报的问题：层次化文件系统，统一文件格式以获得一致的编程接口和通用工具等。特定语言的智能化编辑器在现实中还没有得到广泛应用，不过它们最有希望实现的是消除语法错误和简单的语义错误。

开发环境上，现在已经实现的最大成果可能是集成数据库的使用，用来跟踪大量的开发细节，供每个程序员精确地查阅信息，并在整个团队协作开发中保持最新的状态。

显然，这样的工作是非常有价值的，它能带来软件生产率和可靠性方面的一些提高。但是，由于自身的特性，目前它的回报应该很有限。

工作站。随着工作站的处理能力和内存容量的稳固和快速提高，我们能期望在软件领域取得多大的收获呢？有多少MIPS可供自由使用呢？现在的运算速度已经可以完全满足程序编制和文档书写的需要了。编译还需要一些提高，不过一旦机器运算速度提高十倍，程序开发人员的思考活动将成为日常工作的主要活动。实际上，这已经是现在的情况了。

我们当然欢迎更加强大的工作站，但是不能期望有魔术般的提高。