没有银弹-软件工程中的根本和次要问题

没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量 级上的进步。

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

摘要1

所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构，次要任务 ——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。软件生 产率在近年内取得的巨大进步来自对后天障碍的突破，例如硬件的限制、笨拙的编程语言、 机器时间的缺乏等等。这些障碍使次要任务实施起来异常艰难，相对必要任务而言，软件工 程师在次要任务上花费了多少时间和精力?除非它占了所有工作的 9/10，否则即使全部次 要任务的时间缩减到零，也不会给生产率带来数量级上的提高。

因此，现在是关注软件任务中的必要活动的时候了，也就是那些和构造异常复杂的抽 象概念结构有关的部分。我建议:

仔细地进行市场调研，避免开发已上市的产品。
在获取和制订软件需求时，将快速原型开发作为迭代计划的一部分。
有机地更新软件，随着系统的运行、使用和测试，逐渐添加越来越多的功能。

不断挑选和培养杰出的概念设计人员。
- 102 -

介绍

在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟 悉的面孔变成可怕的怪物。为了对付人狼，我们在寻找可以消灭它们的银弹。

大家熟悉的软件项目具有一些人狼的特性(至少在非技术经理看来)，常常看似简单明 了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到 了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样降低的尚方 宝剑。

但是，我们看看近十年来的情况，没有银弹的踪迹。没有任何技术或管理上的进展， 能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。本章中，我们试图通过分 析软件问题的本质和很多候选银弹的特征，来探索其原因。

不过，怀疑论者并不是悲观主义者。尽管我们没有看见令人惊异的突破，并认为这种 银弹实际上是与软件的内在特性相悖，不过还是出现了一些令人振奋的革新。这些方法的规 范化、持续地开拓、发展和传播确实是可以在将来使生产率产生数量级上的提高。虽然没有 通天大道，但是路就在脚下。

解决管理灾难的第一步是将大块的“巨无霸理论”替换成“微生物理论”，它的每一步 ——希望的诞生，本身就是对一蹴而就型解决方案的冲击。它告诉工作者进步是逐步取得的， 伴随着辛勤的劳动，对规范化过程应进行持续不懈的努力。由此，诞生了现在的软件工程。

是否一定那么困难呢?——根本困难

不仅仅是在目力所及的范围内，没有发现银弹，而且软件的特性本身也导致了不大可 能有任何的发明创新——能够像计算机硬件工业中的微电子器件、晶体管、大规模集成一样 ——提高软件的生产率、可靠性和简洁程度。我们甚至不能期望每两年有一倍的增长。

首先，我们必须看到这样的畸形并不是由于软件发展得太慢，而是因为计算机硬件发 展得太快。从人类文明开始，没有任何其他产业技术的性价比，能在 30 年之内取得 6 个数 量级的提高，也没有任何一个产业可以在性能提高或者降低成本方面取得如此的进步。这些

- 103 -

进步来自计算机制造产业的转变，从装配工业转变成流水线工业。

其次，让我们通过观察预期的软件技术产业发展速度，来了解中间的困难。效仿亚里 士多德，我将它们分成根本的——软件特性中固有的困难，次要的——出现在目前生产上的， 但并非那些与生俱来的困难。

  我们在下一章中讨论次要问题。首先，来关注内在、必要的问题。

一个相互牵制关联的概念结构，是软件实体必不可少的部分，它包括:数据集合、数 据条目之间的关系、算法、功能调用等等。这些要素本身是抽象的，体现在相同的概念构架 中，可以存在不同的表现形式。尽管如此，它仍然是内容丰富和高度精确的。

我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概 念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多 数系统中的概念错误相比，它们是微不足道的。

  如果这是事实，那么软件开发总是非常困难的。天生就没有银弹。

让我们来考虑现代软件系统中这些无法规避的内在特性:复杂度、一致性、可变性和 不可见性。

复杂度。规模上，软件实体可能比任何由人类创造的其他实体要复杂，因为没有任何 两个软件部分是相同的(至少是在语句的级别)。如果有相同的情况，我们会把它们合并成 供调用的子函数。在这个方面，软件系统与计算机、建筑或者汽车大不相同，后者往往存在 着大量重复的部分。

数字计算机本身就比人类建造的大多数东西复杂。计算机拥有大量的状态，这使得构 思、描述和测试都非常困难。软件系统的状态又比计算机系统状态多若干个数量级。

同样，软件实体的扩展也不仅仅是相同元素重复添加，而必须是不同元素实体的添加。 大多数情况下，这些元素以非线性递增的方式交互，因此整个软件的复杂度以更大的非线性 级数增长。

软件的复杂度是必要属性，不是次要因素。因此，抽掉复杂度的软件实体描述常常也 去掉了一些本质属性。数学和物理学在过去三个世纪取得了巨大的进步，数学家和物理学家 们建立模型以简化复杂的现象，从模型中抽取出各种特性，并通过试验来验证这些特性。这

- 104 -

些方法之所以可行——是因为模型中忽略的复杂度不是被研究现象的必要属性。当复杂度是 本质特性时，这些方法就行不通了。

上述软件特有的复杂度问题造成了很多经典的软件产品开发问题。由于复杂度，团队 成员之间的沟通非常困难，导致了产品瑕疵、成本超支和进度延迟;由于复杂度，列举和理 解所有可能的状态十分困难，影响了产品的可靠性;由于函数的复杂度，函数调用变得困难， 导致程序难以使用;由于结构性复杂度，程序难以在不产生副作用的情况下用新函数扩充; 由于结构性复杂度，造成很多安全机制状态上的不可见性。

复杂度不仅仅导致技术上的困难，还引发了很多管理上的问题。它使全面理解问题变 得困难，从而妨碍了概念上的完整性;它使所有离散出口难以寻找和控制;它引起了大量学 习和理解上的负担，使开发慢慢演变成了一场灾难。

一致性。并不是只有软件工程师才面对复杂问题。物理学家甚至在非常“基础”的级 别上，面对异常复杂的事物。不过，物理学家坚信必定存在着某种通用原理，或者在夸克中， 或者在统一场论中。爱因斯坦曾不断地重申自然界一定存在着简化的解释，因为上帝不是专 横武断或反复无常的。

软件工程师却无法从类似的信念中获得安慰，他必须控制的很多复杂度是随心所欲、 毫无规则可言的，来自若干必须遵循的人为惯例和系统。它们随接口的不同而改变，随时间 的推移而变化，而且，这些变化不是必需的，仅仅由于它们是不同的人——而非上帝——设 计的结果。

某些情况下，因为是开发最新的软件，所以它必须遵循各种接口。另一些情况下，软 件的开发目标就是兼容性。在上述的所有情况中，很多复杂性来自保持与其他接口的一致， 对软件的任何再设计，都无法简化这些复杂特性。

可变性。软件实体经常会遭受到持续的变更压力。当然，建筑、汽车、计算机也是如 此。不过，工业制造的产品在出厂之后不会经常地发生修改，它们会被后续模型所取代，或 者必要更改会被整合到具有相同基本设计的后续产品系列。汽车的更改十分罕见，计算机的 现场调整时有发生。然而，它们和软件的现场修改比起来，都要少很多。

其中部分的原因是因为系统中的软件包含了很多功能，而功能是最容易感受变更压力 的部分。另外的原因是因为软件可以很容易地进行修改——它是纯粹思维活动的产物，可以

- 105 -

无限扩展。日常生活中，建筑有可能发生变化，但众所周知，建筑修改的成本很高，从而打 消了那些想提出修改的人的念头。

所有成功的软件都会发生变更。现实工作中，经常发生两种情况。当人们发现软件很 有用时，会在原有应用范围的边界，或者在超越边界的情况下使用软件。功能扩展的压力主 要来自那些喜欢基本功能，又对软件提出了很多新用法的用户们。

其次，软件一定是在某种计算机硬件平台上开发，成功软件的生命期通常比当初的计 算机硬件平台要长。即使不是更换计算机，则有可能是换新型号的磁盘、显示器或者打印机。 软件必须与各种新生事物保持一致。

简言之，软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算 机硬件等等。后者持续不断地变化着，这些变化无情地强迫着软件随之变化。

不可见性。软件是不可见的和无法可视化的。例如，几何抽象是强大的工具。建筑平 面图能帮助建筑师和客户一起评估空间布局、进出的运输流量和各个角度的视觉效果。这样， 矛盾变得突出，忽略的地方变得明显。同样，机械制图、化学分子模型尽管是抽象模型，但 都起了相同的作用。总之，都可以通过几何抽象来捕获物理存在的几何特性。

软件的客观存在不具有空间的形体特征。因此，没有已有的表达方式，就像陆地海洋 有地图、硅片有膜片图、计算机有电路图一样。当我们试图用图形来描述软件结构时，我们 发现它不仅仅包含一个，而是很多相互关联、重叠在一起的图形。这些图形可能描绘控制流 程、数据流、依赖关系、时间序列、名字空间的相互关系等等。它们通常不是有较少层次的 扁平结构。实际上，在上述结构上建立概念控制的一种方法是强制将关联分割，直到可以层 次化一个或多个图形 2。

除去软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性， 从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过 程，也严重地阻碍了相互之间的交流。