了软件构建上的巨大困难，但是这些困难不是本质属性，也不是主要困难。同样，我们可以
- 106 -
----------------------- Page 119-----------------------
对每一次进步进行外推，来了解它们的固有限制。
高级语言。勿庸置疑，软件生产率、可靠性和简洁性上最有力的突破是使用高级语言
编程。大多数观察者相信开发生产率至少提高了五倍，同时可靠性、简洁性和理解程度也大
为提高。
那么，高级语言取得了哪些进展呢？首先，它减轻了一些次要的软件复杂度。抽象程
序包含了很多概念上的要素：操作、数据类型、流程和相互通讯，而具体的机器语言程序则
关心位、寄存器、条件、分支、通道、磁盘等等。高级语言所达到的抽象程度包含了（抽象）
程序所需要的要素，避免了更低级的元素，它消除了并不是程序所固有的整个级别的复杂度。
高级语言最可能实现的是提供所有编程人员在抽象程序中能想到的要素。可以肯定的
是，我们思考数据结构、数据类型和操作的速度稳固提高，不过是以非常缓慢的速度。另外，
程序开发方法越来越接近用户的复杂度。
然而，对于较少使用那些复杂深奥语言要素的用户，高级语言在某种程度上增加而不
是减少了脑力劳动上的负担。
分时。大多数观察者相信分时提高了程序员的生产率和产品的质量，尽管它带来的进
步不如高级语言。
分时解决了完全不同的困难。分时保证了及时性，从而使我们能维持对复杂程度的一
个总体把握。批处理编程的较长周转时间意味着不可避免会遗忘一些细枝末节，如果我们停
下编程，调用编译程序或者执行程序，思维上的中断使我们不得不重新进行思考，它在时间
上的代价非常高昂。最严重的结果可能是失去对复杂系统的掌握。
较长的周转时间和机器语言的复杂度一样，是软件开发过程的次要困难，而不是本质
困难。分时所起作用也非常有限。主要效果是缩短了系统的响应时间。随着它接近于零，到
达人类可以辨识的基本能力——大概100毫秒时，所获得的好处就接近于无了。
统一编程环境。第一个集成开发环境——Unix和Interlisp 现在已经得到了广泛应用，
并且使生产率提高了5倍。为什么？
它们主要通过提供集成库、统一文件格式、管道和过滤器，解决了共同使用程序的次
要困难。这样，概念性结构理论上的相互调用、提供输入和互相使用，在现实中可以非常容
易地实现。
- 107 -
----------------------- Page 120-----------------------
因为每个新工具可以通过标准格式在任何一个程序中应用，这种突破接着又激发整个
工具库的开发。
由于这些成功，环境开发是当今软件工程研究的主要题目。我们将在下章中讨论期望
达到的目标和限制。
银弹的希望
现在，让我们来讨论一下当今可能作为潜在银弹的最先进的技术进步。它们各自针对
什么样的问题？它们是属于必要问题，或者依然是解决我们剩下的次要困难？它们是提供了
创新，还是仅仅是增量改进？
Ada 和其他高级编程语言。近来，最被吹捧的开发进展之一是编程语言Ada，一种80
年代的高级语言。Ada 实际上不仅仅反映了语言概念上的突破性进展，而且蕴涵了鼓励现代
设计和模块化概念运用的重要特性。由于Ada采用的是抽象数据类型、层次结构的模块化理
念，所有Ada 理念可能比语言本身更加先进。Ada使用设计来承载需求，作为这一过程的自
然产物，它可能过于丰富了。不过，这并不是致命的，因为它的词汇子集可以解决学习问题，
硬件的进展能提供更高的MIPS （每秒百万指令集），减少编译的成本。软件系统结构化的先
进理念实际上非常好地利用了MIPS上的进展。60 年代，曾在内存和速度成本上广受谴责的
操作系统，如今已被证明是一种能使用某些MIPS 和廉价内存的非常优秀的系统。
然而，Ada 仍然不是消灭软件生产率怪兽的银弹。毕竟，它只是另一种高级语言，这类
语言出现最大的回报来自出现时的冲击，它通过使用更加抽象的语句来开发，降低了机器的
次要复杂度。一旦这些难题被解决，就只剩下非常少的问题，解决剩余部分的获益必然也要
少一些。
我预言在以后的十年中，当Ada 的效率被大家评估认可时，它会带来相当大的变化，
这并不是因为任何特别的语言特性，不是由于这些语言特性被合并在一起，也不是因为Ada
开发环境会不断发展进步。Ada 的最大贡献在于编程人员培训方式的转变，即对开发人员需
要进行现代软件设计技术培训。
面向对象编程。软件专业的一些学生坚持面向对象编程是当今若干新潮技术中最富有
希望的3。我也是其中之一。达特茅斯的Mark Sherman 提出，必须仔细地区别两个不同的概
- 108 -
----------------------- Page 121-----------------------
念：抽象数据类型和层次化类型，后者也被称为类（class）。抽象数据类型的概念是指对象
类型应该通过一个名称、一系列合适的值和操作来定义，而不是理应被隐藏的存储结构。抽
象数据类型的例子是Ada 包（以及私有类型）和Modula 的模块。
层次化类型，如Simula-67 的类，是允许定义可以被后续子类型精化的通用接口。这
两个概念是互不相干的——可以只有层次化，没有数据隐藏；也可能是只有数据隐藏，而没
有层次化。两种概念都体现了软件开发领域的进步。
它们的出现都消除了开发过程中的非本质困难，允许设计人员表达自己设计的内在特
性，而不需要表达大量句法上的内容，这些内容并没有添加什么新的信息。对于抽象数据类
型和层次化类型，它们都是解决了高级别的次要困难和允许采用较高层次的表现形式来表达
设计。
不过，这些提高仅仅能消除所有设计表达上的次要困难。软件的内在问题是设计的复
杂度，上述方法并没有对它有任何的促进。除非我们现在的编程语言中，不必要的低层次类
型说明占据了软件产品设计 90％，面向对象编程才能带来数量级上的提高。对面向对象编
程这颗“银弹”，我深表怀疑。
人工智能。很多人期望人工智能上的进展可以给软件生产率和质量带来数量级上的增
长4，但我不这样认为。追究其原因，我们必须剖析“人工智能”意味着什么，以及它如何
应用。
Parnas 澄清了术语上的混乱：
现在有两种差异非常大的AI 定义被广泛使用。AI-1：使用计算机来解决以前只能通过
人类智慧解决的问题。AI-2：使用启发式和基于规则的特定编程技术。在这种方法中，对人
类专家进行研究，判断他们解决方法的启发性思维或者经验法则……。程序被设计成以人类
解决问题的方式来运作。
第一种定义的意义容易发生变化……今天可能适合AI-1定义的程序，一旦我们了解了
它的运行方式，理解了问题，就不再认为它是人工智能……不幸的是，我无法识别这个领域
的特定知识体系……绝大多数工作是针对问题域的，我们需要一些抽象或者创造性来解决上
5
述问题 。
我完全同意这种批评意见。语音识别技术与图象识别技术的共同点非常少，它们与专
- 109 -
----------------------- Page 122-----------------------
家系统中应用的技术不同。例如，我觉得很难去发现图象识别技术能给编程开发实践带来什
么样的差异。同样，语音识别也差不多——软件开发上的困难是决定说什么，而不是如何说。
表达的简化仅仅能提供少量的促进作用。
至于AI-2 专家系统技术，应该用专门的章节来讨论。
专家系统。人工智能领域最先进的、被最大范围使用的部分，是开发专家系统的技术。
很多软件科学家正非常努力地工作着，想把这种技术应用在软件的开发环境中5。那么它的
概念是什么，前景如何？
专家系统是包含归纳推论引擎和规则基础的程序，它接收输入数据和假设条件，通过
从基础规则推导逻辑结果，提出结论和建议，向用户展示前因后果，并解释最终的结果。推
论引擎除了处理推理逻辑以外，通常还包括复杂逻辑或者概率数据和规则。
对于解决相同的问题，这种系统明显比传统的程序算法要先进很多。
推导引擎技术的开发独立于应用程序，因此可以用于多个用户。在该引擎上花费较
大的工作是很合理的。实际上，这种引擎技术非常先进。
基于应用的、可变更的部分，在基础规则中以一种统一的风格编码，并且为规则基
础的开发、更改、测试和文档化提供了若干工具。这实际上对一些应用程序本身的复杂度进
行了系统化。
EdwardFeigenbaum 指出这种系统的能力不是来自某种前所未有的推导机制，而是来自
非常丰富的知识积累基础，所以更加精确地反映了现实世界。我认为这种技术提供的最重要
进步是具体应用的复杂性与程序本身相分离。
如何把它应用在软件开发工作中？可以通过很多途径：建议接口规则、制订测试策略、
记录各种bug 产生的频率、提供优化建议等等。
例如，考虑一个虚构的测试顾问系统。在最根本的级别，诊断专家系统和飞行员的检
查列表很相似，对可能难以寻找的原因提供基本的建议。建立基础规则时，可以依据更多的
复杂问题征兆报告，从而使这些建议更加精确。可以想象，该调试辅助程序起初提供的是一
般化建议，随着基础规则包括越来越多的系统结构信息时，它产生的推测和推荐的测试也越
来越准确。该类型的专家系统可能与传统系统彻底分离，系统中的规则基础可能与相应的软
件产品具有相同的层次模块化结构，因此当产品模块化修改时，诊断规则也能相应地进行模
- 110 -
----------------------- Page 123-----------------------
块化修改。
产生诊断规则也是在为模块和系统编制测试用例集时必须完成的任务。如果它以一种
适当通用的方式来完成，对规则采用一致的结构，拥有一个良好可用的推测引擎，那么事实
上它就可以减少测试用例设计的总体工作量，以及帮助整个软件生命周期的维护、修改和测
试。同样，我们可以推测其他的顾问专家系统——可能是它们中的某一些，或者是较简单的
系统——能够用在软件开发的其他部分。
在较早实现的用于软件开发的专家顾问系统中，存在着很多困难。在我们假设的例子
中，一个关键的问题是寻找一种方法，能从软件结构的技术说明中，自动或者半自动地产生
诊断规则。另外，更加重要也是更加困难的任务是：寻觅能够清晰表达、深刻理解为什么的
分析专家；开发有效的技术——抽取专家们所了解的知识，把它们精炼成基础规则。这项工
作的工作量是知识获取工作量的两倍。构建专家系统的必要前提条件是拥有专家。
专家系统最强有力的贡献是给缺乏经验的开发人员提供服务，用最优秀开发者的经验
和知识积累为他们提供了指导。这是非常大的贡献。最优秀和一般的软件工程实践之间的差
距是非常大的，可能比其他工程领域中的差距都要大，一种传播优秀实践的工具特别重要。
“自动”编程。近四十年中，人们一直在预言和编写有关“自动编程”的文字，从问
题的一段陈述说明自动产生解决问题的程序。现在，仍有一些人期望这样的技术能够成为下
7
一个突破点 。
Parnas 暗示这是一个用于魔咒的术语，声称它本身是语义不完整的。
8
一句话，自动编程总是成为一种热情，使用现在并不可用的更高级语言编程的热情 。
他指出，大多数情况下所给出的技术说明本质上是问题的解决方法，而不是问题自身。
可以找到一些例外情况。例如，数据发生器的开发技术就非常实用，并经常地用于排
序程序中。系统评估若干参数，从问题解决方案库中进行选择，生成合适的程序。
这样的应用具有非常良好的特性：
问题通过相对较少的参数迅速地描述出特征。
存在很多已知的解决方案，提供了可供选择的库。
在给定问题参数的前提下，大量广泛的分析为选择具体的解决技术提供了清晰的规
- 111 -
----------------------- Page 124-----------------------
则。
具有上述简洁属性的系统是一个例外，很难看到该方法能普及到更广泛的寻常软件系
统，甚至难以想象这种突破如何能够进行推广。
图形化编程。在软件工程的博士论文中，一个很受欢迎的主题是图形化和可视化编程，
计算机图形在软件设计上的应用9。这种方法的推测部分来自VLSI 芯片设计的类比，计算机
图形化在设计中扮演了高生产力的角色。部分源于——人们将流程图作为一种理想的设计介
质，并为绘制它们提供了很多功能强大的实用程序——这证实了图形化的可行性。
不过，上述方法中至今还没有出现任何令人信服和激动的进步。我确信将来也不会出
现。
首先，如同我先前所提出的，流程图是一种非常差劲软件结构表达方法10。实际上，它
最好被视为是冯．诺依曼、戈尔德斯廷和勃克斯试图为他们所设计的计算机提供的一种当时
迫切需要的高级控制语言。如今的流程图已经变得复杂，一张图有若干页，有很多连接结点。
这种表现形式实在令人同情。流程图已经成为完全不必要的设计工具——程序员在开发之
后，而不是之前绘制描述程序的流程图。
其次，现在的屏幕非常小，像素级别，无法同时表现软件图形的所有正式、详细的范
围和细节。现在所谓 “类似桌面”的工作站实际上像是“飞机坐舱座椅”。飞机上，任何坐
在两个肥胖乘客之间，反复挪动一大兜文件的人会意识到这中间的差别——每次只能看到很
少的内容。真正的桌面提供了很多文件的总览，让大家可以随意地使用它们。此外，当人们
的创造力一阵阵地涌现时，开发人员大多数都会舍弃工作台，使用空间更为广阔的地板。要
使我们面对的工作空间满足软件开发工作的需要，硬件技术必须进一步发展。
更加基本的是，如同我们上面所争论的，软件非常难以可视化。即使用图形表达出了
流程图、变量范围嵌套情况、变量交叉引用、数据流、层次化数据结构等等，也只是表达了
某个方面，就像盲人摸象一样。如果我们把很多相关的视图叠加在所产生的图形上，那么很
难再抽取出全局的总体视图。对VLSI 芯片设计方法的类推是一种误导——芯片设计是对两
维对象的层次设计，它的几何特性反映了它的本质特性，而软件系统不是这样。
程序验证。现代编程的许多工作是测试和修复bug。是否有可能出现银弹，能够在系统
设计级别、源代码级别消除bug 呢？是否可以在大量工作被投入到实现和测试之前，通过采
- 112 -
----------------------- Page 125-----------------------
用证实设计正确性的“深奥”策略，彻底提高软件的生产率和产品的可靠性？
我并不认为在这里能找到魔法。程序验证的确是很先进的概念，它对安全操作系统内
核等这类应用是非常重要的。不过，这项技术并不能保证节约劳动力。验证要求如此多的工
作量，以致于只有少量的程序能够得到验证。
程序验证不意味着零缺陷的程序。这里并没有什么魔术，数学验证仍然可能是有错误
的。因此，尽管验证可能减少程序测试的工作量，但却不能省略程序测试。
更严肃地说，完美的程序验证只能建立满足技术说明的程序。这时，软件工作中最困
难的部分已经接近完成，形成了完整和一致的说明。开发程序的一些必要工作实际上已经变
成对技术规格说明进行测试。
环境和工具。向更好的编程开发环境开发中投入，我们可以期待得到多少回报呢？人
们的本能反应是首先着手解决高回报的问题：层次化文件系统，统一文件格式以获得一致的
编程接口和通用工具等。特定语言的智能化编辑器在现实中还没有得到广泛应用，不过它们
最有希望实现的是消除语法错误和简单的语义错误。
开发环境上，现在已经实现的最大成果可能是集成数据库的使用，用来跟踪大量的开
发细节，供每个程序员精确地查阅信息，以及在整个团队协作开发中保持最新的状态。
显然，这样的工作是非常有价值的，它能带来软件生产率和可靠性上的一些提高。但
是，由于它自身的特性，目前它的回报很有限。
工作站。随着工作站的处理能力和内存容量的稳固和快速提高，我们能期望在软件领
域取得多大的收获呢？现在的运算速度已经可以完全满足程序编制和文档书写的需要。编译
还需要一些提高，不过一旦机器运算速度提高十倍，那么程序开发人员的思考活动将成为日
常工作的主要活动。实际上，这已经是现在的情况。
我们当然欢迎更加强大的工作站，但是不能期望有魔术般的提高。
针对概念上根本问题的颇具前途的方法
虽然现在软件上没有技术上的突破能够预示我们可以取得像在硬件领域上一样的进
