无银弹——软件工程的本质性难题与偶然性难题

注：本文为 “软件工程” 相关译文，机翻未校，如有内容异常，请看原文。

No Silver Bullet – Essence and Accidents of Software Engineering

无银弹——软件工程的本质性难题与偶然性难题

TR86-020 September 1986 1986 年 9 月 Frederick P. Brooks, Jr. 小弗雷德里克·P·布鲁克斯

The University of North Carolina at Chapel Hill Department of Computer Science CB#3175, Sitterson Hall Chapel Hill, NC 27599-3175 北卡罗来纳大学教堂山分校计算机科学系，邮编 CB#3175，西特森楼，北卡罗来纳州教堂山市，邮编 27599-3175

UNC is an Equal Opportunity/Affirmative Action Institution. 北卡罗来纳大学秉持机会均等、平权招生办学准则。

TR86-020, September, 1986 Doc. 860905 1986 年 9 月，文档编号 860905，技术报告 TR86-020

Frederick P. Brooks, Jr. Kenan Professor of Computer Science University of North Carolina at Chapel Hill New West Hall 035A Chapel Hill, North Carolina 27514 USA

小弗雷德里克·P·布鲁克斯 美国北卡罗来纳大学教堂山分校肯南计算机科学讲席教授，新西楼 035A，北卡罗来纳州教堂山市，邮编 27514

Abstract

摘要

All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement. 所有软件构建工作都包含两类任务：本质性任务，即搭建构成抽象软件实体的复杂概念结构；偶然性任务，即用编程语言对抽象实体进行表达，并在存储空间与运行速度约束下将其映射为机器语言。过去软件生产效率的大幅提升，大多源于消除了人为制造的阻碍——这类阻碍大幅加重了偶然性任务的难度，例如严苛的硬件限制、晦涩难用的编程语言、计算机机时不足。如今软件工程师的工作中，偶然性任务与本质性任务各自占比如何？除非偶然性工作占用超过 9/10 的总工作量，否则即便将所有偶然性工作耗时缩减至零，也无法实现一个数量级的效率提升。

Therefore it appears that the time has come to address the essential parts of the software task, those concerned with fashioning abstract conceptual structures of great complexity. I suggest: • exploiting the mass market to avoid constructing what can be bought. • using rapid prototyping as part of a planned iteration in establishing software requirements. • growing software organically, adding more and more function to systems as they are run, used, and tested. • identifying and developing the great conceptual designers of the rising generation. 由此可见，当下应当着手解决软件工作中的本质性难题，也就是构建高度复杂抽象概念结构的相关工作。本文提出如下四点思路：• 充分利用大众软件市场，尽可能采购现成软件，避免从零开发。• 将快速原型作为规划迭代流程的一环，用于梳理软件需求。• 采用有机增量式开发软件，在系统运行、使用与测试过程中持续迭代新增功能。• 发掘并培养新一代顶尖软件架构设计者。

1. INTRODUCTION

1 引言

Of all the monsters who fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest. 民间传说里充斥着各类噩梦怪物，其中狼人最令人恐惧，它会毫无征兆地从寻常模样变为可怖怪物。人们苦苦寻找银弹，希望凭其魔力一举制服狼人。

The familiar software project has something of this character (at least as seen by the non-technical manager), usually innocent and straightforward, but capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet, something to make software costs drop as rapidly as computer hardware costs do. 常规软件项目也有着类似特质（至少在非技术管理者眼中如此）：初期看似简单清晰，却极易演变成工期延误、预算超支、产品缺陷百出的棘手难题。于是人们急切期盼一枚“银弹”，能让软件成本像计算机硬件成本那样飞速下降。

But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity. In this paper we shall try to see why, by examining both the nature of the software problem and the properties of the bullets proposed. 但放眼未来十年，并不存在这样一枚银弹。无论技术手段还是管理方法，不存在任何单一突破能仅凭自身，让软件的生产效率、可靠性、简洁度实现一个数量级的提升。本文将剖析软件问题的内在特质，以及各类被寄予厚望的方案的局限性，阐释为何不存在万能银弹。

Skepticism is not pessimism, however. Although we see no startling breakthroughs, and indeed, believe such to be inconsistent with the nature of software, many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate, and exploit them should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road. 但质疑不等于悲观。尽管不存在颠覆性的突破性技术，且从软件自身特质来看这类突破本就不可能出现，但当下已有诸多具备前景的创新正在落地。只要有条理、持续地研发、推广、落地这些创新，终究能够达成一个数量级的效率提升。软件工程不存在捷径，但存在可行的渐进式发展路径。

The first step toward the management of disease was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering today. 人类攻克疾病的第一步，是摒弃妖魔致病、体液失衡等旧学说，建立病菌致病理论。这一充满希望的转变，同时击碎了人们对神奇特效药的幻想。它告诉医疗从业者：进步只能循序渐进，需要付出巨大努力，且必须长期恪守标准化的卫生规范。如今的软件工程亦是同理。

2. DOES IT HAVE TO BE HARD? -ESSENTIAL DIFFICULTIES

2 软件开发本就注定艰难吗？——本质性难题

Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any – no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, large-scale integration did for computer hardware. We cannot expect ever to see two-fold gains every two years. 不仅当下看不到银弹，软件自身的特质也决定了银弹不可能出现：不存在任何发明，能像电子管、晶体管、大规模集成电路革新计算机硬件那样，彻底提升软件的效率、可靠性与简洁度。我们无法期待软件性能每两年实现翻倍提升。

First, one must observe that the anomaly is not that software progress is so slow, but that computer hardware progress is so fast. No other technology since civilization began has seen six orders of magnitude price-performance gain in 30 years. In no other technology can one choose to take the gain in either improved performance or in reduced costs. These gains flow from the transformation of computer manufacture from an assembly industry into a process industry. 首先要认清一个客观事实：反常的并非软件发展缓慢，而是计算机硬件迭代速度过于惊人。自有人类文明以来，没有任何一项技术能在 30 年内实现性价比六个数量级的提升。其他技术都无法兼顾性能提升与成本下降两种收益。硬件的巨大进步源于计算机制造模式的转变：从组装加工产业转变为流程化工产业。

Second, to see what rate of progress one can expect in software technology, let us examine its difficulties. Following Aristotle, I divide them into essence, the difficulties inherent in the nature of the software, and accidents, those difficulties which today attend its production but which are not inherent. The accidents I discuss in the next section. First let us consider the essence. 其次，若想预判软件技术的发展速度，我们需要梳理软件开发存在的各类难点。本文借鉴亚里士多德的分类思想，将难点分为两类：本质性难题，即软件与生俱来、无法剥离的固有难点；偶然性难题，即当下软件开发过程中存在、但并非软件自带的难点。偶然性难题将在下一节展开，本节先探讨本质性难题。

The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed. 软件实体由一套相互关联的概念组合构成：数据集、数据项间的关联关系、算法、函数调用逻辑。这套组合具备抽象属性：同一套概念结构可通过多种不同形式表达。但这套抽象结构本身又具备极高的精确性与海量细节。

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems. 软件开发真正的难点在于这套概念结构的需求定义、设计与验证，而非将其编写为代码、校验代码是否贴合设计的重复劳动。当然开发过程中仍会出现语法错误，但和绝大多数系统中存在的逻辑偏差相比，语法错误只是微不足道的小问题。

If this is true, building software will always be hard. There is inherently no silver bullet. 若以上观点成立，软件开发将永远存在固有难点，银弹从根源上不可能存在。

Let us consider the inherent properties of this irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility. 现代软件这套无法简化的内在组合，具备四项固有属性：复杂性、适配约束性、易变性、不可可视化。

2.1 Complexity

2.1 复杂性

Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a subroutine, open or closed. In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound. 同等规模下，软件实体的复杂程度远超人类创造的其他产物，因为软件不存在两段完全相同的逻辑单元（至少在语句层级之上）。若出现重复逻辑，开发者会将其封装为统一子程序，分为公开接口或私有内部实现。这一点和计算机、建筑、汽车有着本质区别：后者存在大量重复标准化构件。

Digital computers are themselves more complex than most things people build; they have very large numbers of states. This makes conceiving, describing, and testing them hard. Software systems have orders of magnitude more states than computers do. 数字计算机本身的复杂度已超过绝大多数人工造物，具备海量运行状态。这使得计算机的设计、描述、测试工作难度极高。而软件系统的状态数量，比计算机硬件还要高出数个数量级。

Likewise, a scaling-up of a software entity is not merely a repetition of the same elements in larger size, it is necessarily an increase in the number of different elements. In most cases, the elements interact with each other in some non-linear fashion, and the complexity of the whole increases much more than linearly. 同理，软件规模扩张并非简单重复原有单元，而是必然新增大量全新逻辑单元。多数场景下单元之间呈非线性交互关系，整体复杂度的增长速度远高于规模线性增长速度。

The complexity of software is an essential property, not an accidental one. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence. Mathematics and the physical sciences for three centuries made great strides by constructing simplified models of complex phenomena, deriving properties from the models, and verifying those properties experimentally. This worked because the complexities ignored in the models were not the essential properties of the phenomena. It does not work when the complexities are the essence. 软件的复杂性是固有属性，而非偶然产生的问题。因此，若简化描述时剥离软件的复杂性，往往会同时丢失软件内在组合。过去三百年间，数学与物理科学通过为复杂自然现象建立简化模型、推导模型特性、实验验证特性实现飞速发展。这套方法能够奏效，是因为模型舍弃的复杂细节并非现象的固有属性。但软件的复杂性就是其内在构成，这套简化建模思路不再适用。

Many of the classical problems of developing software products derive from this essential complexity and its non-linear increases with size. From the complexity comes the difficulty of communication among team members, which leads to product flaws, cost overruns, schedule delays. From the complexity comes the difficulty of enumerating, much less understanding, all the possible states of the program, and from that comes the unreliability. From the complexity of the functions comes the difficulty of invoking those functions, which makes programs hard to use. From complexity of structure comes the difficulty of extending programs to new functions without creating side effects. From complexity of structure come the unvisualized states that constitute security trapdoors. 软件产品开发中的诸多经典问题，都源于这种固有复杂度，以及复杂度随规模非线性暴涨的特性。复杂性带来团队沟通障碍，进而引发产品缺陷、成本超支、工期延误。复杂性让开发者无法穷举、更无法完整理解程序全部运行状态，直接造成软件可靠性不足。功能逻辑复杂导致调用逻辑晦涩，软件易用性大幅下降。软件结构复杂，新增功能时极易产生难以预料的副作用，拓展维护难度极高。复杂结构中存在大量无法直观梳理的隐藏状态，形成安全漏洞隐患。

Not only technical problems, but management problems as well come from the complexity. It makes overview hard, thus impeding conceptual integrity. It makes it hard to find and control all the loose ends. It creates the tremendous learning and understanding burden that makes personnel turnover a disaster. 复杂性不仅催生技术难题，也带来管理难题。复杂度让管理者难以全局把控系统，破坏整体设计统一度。难以定位并管控所有未闭环的细节问题。新员工上手理解成本极高，人员流失会对项目造成毁灭性冲击。

2.2 Conformity

2.2 适配约束性

Software people are not alone in facing complexity. Physics deals with terribly complex objects even at the “fundamental” particle level. The physicist labors on, however, in a firm faith that there are unifying principles to be found, whether in quarks or in unified field theories. Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. 并非只有软件从业者需要应对复杂性。物理学研究的基础粒子层面，同样存在极致复杂的研究对象。但物理学家始终坚信存在统一底层规律，无论是夸克理论还是统一场论，都在追寻通用底层法则。爱因斯坦多次提出：自然界必然存在简洁统一的解释，自然规律并非随机、无逻辑的。

No such faith comforts the software engineer. Much of the complexity he must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must conform. These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God. 软件工程师却无法抱有这样的信念。软件需要处理的大量复杂逻辑是人为随机产生的：软件接口必须适配各类人工业务体系与外部系统，而这些外部系统的设计毫无统一规律可言。不同接口、不同时期的规范差异巨大，这类差异并非业务刚需，只是设计者不同造成的人为区别，不存在自然层面的统一规则。

In many cases the software must conform because it has most recently come to the scene. In others it must conform because it is perceived as the most conformable. But in all cases, much complexity comes from conformation to other interfaces; this cannot be simplified out by any redesign of the software alone. 多数场景下，软件作为后开发系统，必须适配已存在的旧系统。另一些场景中，软件被视作改造成本最低的一方，因此需要主动适配其他系统。无论何种场景，大量复杂度都来源于外部接口适配，仅靠重构软件本身无法消除这类复杂度。

2.3 Changeability

2.3 易变性

The software entity is constantly subject to pressures for change. Of course, so are buildings, cars, computers. But manufactured things are infrequently changed after manufacture; they are superseded by later models, or essential changes are incorporated in later serial-number copies of the same basic design. Call-backs of automobiles are really quite infrequent; field changes of computers somewhat less so. Both are much less frequent than modifications to fielded software. 软件始终面临持续变更的需求压力。建筑、汽车、硬件计算机同样会产生变更需求。但实体工业品出厂后极少改造，一般通过推出新型号迭代，核心改动只会应用在后续同架构批次产品中。汽车召回事件十分罕见，硬件计算机现场改造的情况更少。二者的改造频率，远低于已上线软件的迭代修改频率。

Partly this is because the software in a system embodies its function, and the function is the part which most feels the pressures of change. Partly it is because software can be changed more easily – it is pure thought-stuff, infinitely malleable. Buildings do in fact get changed, but the high costs of change, understood by all, serve to dampen the whims of the changers. 一方面，系统的业务逻辑完全由软件承载，业务功能是变更需求最集中的部分。另一方面，软件修改门槛极低：它纯粹由逻辑构成，具备无限可塑性。建筑虽也会改造，但改造成本极高，所有人都清楚这一点，因此不会随意提出改动需求。

All successful software gets changed. Two processes are at work. As a software product is found to be useful, people try it in new cases at the edge of, or beyond, the original domain. The pressures for extended function come chiefly from users who like the basic function and invent new uses for it. 任何获得市场认可的软件，都会持续迭代修改。变更主要来自两类动因。软件投入使用后，用户会将其应用到原有业务边界、甚至超出原有业务范围的全新场景。拓展功能的需求，大多来自认可软件基础能力、并挖掘出新使用场景的用户。

Second, successful software also survives beyond the normal life of the machine vehicle for which it is first written. If not new computers, then at least new disks, new displays, new printers come along; and the software must be conformed to its new vehicles of opportunity. 其二，热门软件的生命周期，往往远超最初配套硬件设备的服役年限。即便计算机主机不变，磁盘、显示器、打印机等外设也会持续更新，软件必须适配全新硬件环境。

In short, the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their changes inexorably force change upon the software product. 简言之，软件产品嵌入在由业务场景、用户群体、法律法规、硬件设备共同构成的环境体系中。上述要素持续迭代，其变化会不可避免地倒逼软件同步修改。

2.4 Invisibility

2.4 不可可视化

Software is invisible and unvisualizable. Geometric abstractions are powerful tools. The floor plan of a building helps both architect and client evaluate spaces, traffic flows, views. Contradictions become obvious, omissions can be caught. Scale drawings of mechanical parts and stick-figure models of molecules, although abstractions, serve the same purpose. A geometric reality is captured in a geometric abstraction. 软件具备不可见、难以可视化的特性。几何抽象是高效的设计辅助工具。建筑平面图能帮助设计师与客户直观评估空间布局、人流动线、视野效果。设计矛盾一目了然，遗漏需求也能快速发现。机械零件比例图纸、分子骨架模型虽属于抽象表达，却具备相同的可视化辅助价值。实体的空间特征可通过几何抽象完整还原。

The reality of software is not inherently embedded in space. Hence it has no ready geometric representation in the way that land has maps, silicon chips have diagrams, computers have connectivity schematics. As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs, superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These are usually not even planar, much less hierarchical. Indeed, one of the ways of establishing conceptual control over such structure is to enforce link cutting until one or more of the graphs becomes hierarchical {1}. 软件的逻辑本身不存在天然的空间几何载体。因此软件无法像土地对应地图、硅芯片对应版图、计算机对应连接原理图那样，拥有标准化几何可视化表达。只要尝试绘制软件结构图就会发现：软件逻辑不是单一图形，而是多张有向图相互叠加。这些分层图形分别代表控制流、数据流、依赖关系、时序逻辑、命名空间关联。这类图形大多无法在平面无交叉绘制，更难以整理为层级树形结构。想要梳理这类复杂结构的逻辑，只能人为切断关联链路，让部分图形简化为层级结构{1}。

In spite of progress in restricting and simplifying the structures of software, they remain inherently unvisualizable, thus depriving the mind of some of its most powerful conceptual tools. This lack not only impedes the process of design within one mind, it severely hinders communication among minds. 尽管业界持续优化软件结构的简化手段，但软件本身依旧难以可视化，人类失去了最直观高效的抽象思考工具。可视化缺失不仅阻碍个人独立设计思考，还会严重降低团队成员间的沟通效率。

3. PAST BREAKTHROUGHS SOLVED ACCIDENTAL DIFFICULTIES

3 过往技术突破仅解决了偶然性难题

If we examine the three steps in software technology that have been most fruitful in the past, we discover that each attacked a different major difficulty in building software, but they have been the accidental, not the essential, difficulties. We can also see the natural limits to the extrapolation of each such attack. 回顾软件工程史上三项成效最显著的技术变革可以发现：它们分别攻克了软件开发中的一类核心难点，但全部属于偶然性难题，并未触及内在组合层面的难点。同时我们也能看出，每一项技术优化的收益都存在天然上限。

3.1 High-Level Languages

3.1 高级编程语言

Surely the most powerful stroke for software productivity, reliability, and simplicity has been the progressive use of high-level languages for programming. Most observers credit that development with at least a factor of five in productivity, and with concomitant gains in reliability, simplicity, and comprehensibility. 逐步普及高级编程语言，无疑是提升软件生产效率、可靠性与简洁度最有力的技术变革。多数业内研究者认为，高级语言至少将开发效率提升 5 倍，同时同步改善了软件可靠性、简洁性与可读性。

What does a high-level language accomplish? It frees a program from much of its accidental complexity. An abstract program consists of conceptual constructs: operations, data types, sequences, and communication. The concrete machine program is concerned with bits, registers, conditions, branches, channels, and disks. To the extent that the high-level language embodies the constructs one wants in the abstract program and avoids all lower ones, it eliminates a whole level of complexity that was never inherent in the program at all. 高级语言的核心价值是什么？它剥离了程序中大量偶然性复杂度。抽象层面的程序由概念单元构成：运算逻辑、数据类型、执行序列、交互通信。而底层机器程序需要处理比特、寄存器、判断跳转、IO通道、磁盘等硬件细节。高级语言完整封装开发者需要的抽象单元，屏蔽底层硬件细节，直接消除了一层不属于程序本身的额外复杂度。

The most a high-level language can do is to furnish all the constructs the programmer imagines in the abstract program. To be sure, the level of our sophistication in thinking about data structures, data types, and operations is steadily rising, but at an ever-decreasing rate. And language development approaches closer and closer to the sophistication of users. 高级语言的能力上限，是完整提供开发者所需的全部抽象逻辑单元。诚然，人类对数据结构、数据类型、运算逻辑的抽象理解持续提升，但提升速度不断放缓。编程语言的抽象层级，会无限贴近开发者的抽象思维层级。

Moreover, at some point the elaboration of a high-level language becomes a burden that increases, not reduces, the intellectual task of the user who rarely uses the esoteric constructs. 此外，当高级语言功能过度堆砌后，反而会加重开发者认知负担：多数开发者极少使用的冷门语法特性，会提升学习与理解成本。

3.2 Time-Sharing

3.2 分时操作系统

Most observers credit time-sharing with a major improvement in the productivity of programmers and in the quality of their product, although not so large as that brought by high-level languages. 多数研究者认为分时系统大幅提升程序员开发效率与软件质量，但提升幅度不及高级编程语言。

Time-sharing attacks a quite different difficulty. Time-sharing preserves immediacy, and hence enables one to maintain an overview of complexity. The slow turnaround of batch programming means that one inevitably forgets the minutae, if not the very thrust, of what he was thinking when he stopped programming and called for compilation and execution. This interruption of consciousness is costly in time, for one must refresh. The most serious effect may well be the decay of grasp of all that is going on in a complex system. 分时系统解决的是另一类偶然性难题。分时系统保障开发者操作即时响应，便于持续把控系统整体复杂度。批处理模式编译运行延迟极高，开发者中断编码提交编译后，极易遗忘之前思考的细节，甚至丢失核心设计思路。思路中断会带来巨大时间损耗，开发者需要重新梳理之前的逻辑。最严重的负面影响，是开发者逐步丧失对复杂系统全局逻辑的掌控力。

Slow turn-around, like machine-language complexities, is an accidental rather than an essential difficulty of the software process. The limits of the contribution of time-sharing derive directly. The principal effect is to shorten system response time. As it goes to zero, at some point it passes the human threshold of noticeability, about 100 milliseconds. Beyond that no benefits are to be expected. 编译执行延迟、机器语言带来的底层复杂度，都属于软件开发的偶然性难题。分时系统带来的效率提升存在清晰上限。其核心作用是缩短系统响应延迟。当延迟无限趋近于零时，会抵达人类感知临界值，约 100 毫秒。延迟低于该阈值后，不会再产生额外效率提升。

3.3 Unified Programming Environments

3.3 一体化编程开发环境

Unix and Inter lisp, the first integrated programming environments to come into widespread use, are perceived to have improved productivity by integral factors. Why? Unix、Interlisp 是最早大规模普及的一体化开发环境，业内公认其将开发效率提升数倍。背后原因是什么？

They attack the accidental difficulties of using programs together, by providing integrated libraries, unified file formats, and pipes and filters. As a result, conceptual structures that in principle could always call, feed, and use one another can indeed easily do so in practice. 这类环境通过集成标准库、统一文件格式、管道与过滤器机制，解决了多程序协同运行的偶然性障碍。由此，理论上可相互调用、传递数据的逻辑单元，在实际开发中能够便捷协同。

This breakthrough in turn stimulated the development of whole toolbenches, since each new tool could be applied to any programs using the standard formats. 这一突破进一步推动全套工具链的发展：所有新工具都可基于统一标准格式，适配任意程序。

Because of these successes, environments are the subject of much of today’s software engineering research. We will look at their promise and limitations in the next section. 正因一体化开发环境成效显著，当下软件工程大量研究围绕工具环境展开。下一节将分析这类方案的发展潜力与固有局限。

4. HOPES FOR THE SILVER

4 各界寄予厚望的各类“银弹方案”

Now let us consider the technical developments that are most often advanced as potential silver bullets. What problems do they address? Are they the problems of essence, or are they remainders of our accidental difficulties? Do they offer revolutionary advances, or incremental ones? 本节逐一分析业界常被视作潜在银弹的各类技术方案。它们解决的是何种问题？是内在层面的难点，还是剩余的偶然性难题？能带来颠覆性提升，还是仅能实现渐进式优化？

4.1 Ada and other High-Level Language Advances

4.1 Ada 语言与其他高级语言演进方案

One of the most touted recent developments is the programming language Ada, a general-purpose high-level language of the '80’s. Ada indeed reflects not only evolutionary improvements in language concepts, but embodies features to encourage modern design and modularization concepts. Perhaps the Ada philosophy is more of an advance than the Ada language, for it is the philosophy of modularization, of abstract data types, of hierarchical structuring. Ada is perhaps over-rich, the natural product of the process by which requirements were laid on its design. That is not fatal, for subset working vocabularies can solve the learning problem, and hardware advances will give us the cheap MIPS to pay for the compiling costs. Advancing the structuring of software systems is indeed a very good use for the increased MIPS our dollars will buy. Operating systems, loudly decried in the '60’s for their memory and cycle costs, have proved to be an excellent form in which to use some of the MIPS and cheap memory bytes of the past hardware surge. Ada 语言是 80 年代广受推崇的通用高级编程语言。Ada 不仅在语言语法理念上完成迭代升级，还内置配套特性，引导开发者采用现代化、模块化设计思路。Ada 承载的设计理念，其价值甚至高于语言本身：模块化、抽象数据类型、分层架构设计思想。Ada 语言特性较为繁杂，这是其需求定义阶段多方诉求叠加的必然结果。但繁杂特性并非致命缺陷：开发者可选用语言子集降低学习成本，硬件算力提升也能以更低成本支撑编译开销。利用硬件算力提升优化软件架构分层，是算力增量的合理应用场景。60 年代操作系统曾因内存、算力开销饱受诟病，但如今硬件算力与存储成本大幅下降，操作系统恰好能够充分利用富余算力与存储资源。

Nevertheless, Ada will not prove to be the silver bullet that slays the software productivity monster. It is, after all, just another high-level language, and the biggest payoff from such languages came from the first transition, up from the accidental complexities of the machine into the more abstract statement of step-by-step solutions. Once those accidents have been removed; the remaining ones are smaller, and the payoff from their removal will surely be less. 但 Ada 无法成为解决软件效率难题的万能银弹。归根结底，它只是另一款高级语言。高级语言带来的最大收益，来自从机器语言到抽象语句的第一次跨越，这一步消除了底层机器带来的偶然性复杂度。底层硬件相关的偶然性复杂度消除后，剩余偶然性问题带来的收益空间会持续收窄。

I predict that a decade from now, when the effectiveness of Ada is assessed, it will be seen to have made a substantial difference, but not because of any particular language feature, nor indeed of all of them combined. Neither will the new Ada environments prove to be the cause of the improvements. Ada’s greatest contribution will be that switching to it occasioned training programmers in modern software design techniques. 十年后回头评估 Ada 的价值会发现：它确实带来了显著改善，但改善并非源于某一项语法特性，也不是全部特性叠加的效果。配套 Ada 开发环境也并非效率提升的核心来源。Ada 最大的价值，是推动开发者系统性学习现代化软件设计方法论。

4.2 Object-Oriented Programming

4.2 面向对象编程

Many students of the art hold out more hope for object-oriented programming than for any of the other technical fads of the day {2}. I am among them. Mark Sherman of Dartmouth notes that one must be careful to distinguish two separate ideas that go under that name: abstract data types and hierarchical types, also called classes. The concept of the abstract data type is that an object’s type should be defined by a name, a set of proper values, and a set of proper operations, rather than its storage structure, which should be hidden. Examples are Ada packages (with private types) or Modula’s modules. 在当年各类热门技术中，多数软件工程从业者对面向对象编程寄予最高期待{2}。行业从业者普遍持有该观点。达特茅斯大学的马克·谢尔曼提出，需要区分面向对象概念下两项独立核心思想：抽象数据类型、分层类型（也称为类）。抽象数据类型的核心思想：对象类型由标识、合法取值集合、合法操作集合定义，底层存储结构对外隐藏。典型实现包含带私有类型的 Ada 包、Modula 模块。

Hierarchical types, such as Simula-67’s classes, allow one to define general interfaces that can be further refined by providing subordinate types. The two concepts are orthogonal – one may have hierarchies without hiding and hiding without hierarchies. Both concepts represent real advances in the art of building software. 分层类型以 Simula-67 的类为代表，支持定义通用基础接口，再通过子类细化拓展能力。两项理念相互独立：可实现分层但不封装隐藏，也可封装隐藏但无分层继承。二者均代表软件开发技术的实质性进步。

Each removes one more accidental difficulty from the process, allowing the designer to express the essence of his design without having to express large amounts of syntactic material that add no new information content. For both abstract types and hierarchical types, the result is to remove a higher-order sort of accidental difficulty and allow a higher-order expression of design. 二者都消除了开发流程中的一类偶然性难点，设计者可直接表达设计内在逻辑，无需编写大量无业务信息的冗余语法代码。抽象数据类型与分层类型，消除了更高层级的偶然性冗余，实现更高抽象层级的设计表达。

Nevertheless, such advances can do no more than to remove all the accidental difficulties from the expression of the design. The complexity of the design itself is essential; and such attacks make no change whatever in that. An order-of-magnitude gain can be made by object-oriented programming only if the unnecessary underbrush of type specification remaining today in our programming language is itself responsible for nine-tenths of the work involved in designing a program product. I doubt it. 但这类优化仅能消除设计表达阶段的偶然性难题。设计自身的复杂度属于内在属性，这类手段无法对此产生任何改变。只有当编程语言中冗余的类型定义工作占整体开发工作量九成以上时，面向对象编程才能带来一个数量级的效率提升。该情况并不成立。

4.3 Artificial Intelligence

4.3 人工智能

Many people expect advances in artificial intelligence to provide the revolutionary breakthrough that will give order-of-magnitude gains in software productivity and quality {3}. I do not. To see why, we must dissect what is meant by “artificial intelligence”, and then see how it applies. 许多人期待人工智能实现颠覆性突破，让软件开发效率与质量提升一个数量级{3}。该预期并不成立。下文拆解“人工智能”的两层定义，分析其在软件开发场景的适用边界。

Pamas has clarified the terminological chaos {4}: Two quite different definitions of AI are in common use today. AI-1: The use of computers to solve problems that previously could only be solved by applying human intelligence. AI-2: The use of a specific set of programming techniques known as heuristic or rule-based programming. In this approach human experts are studied to determine what heuristics or rules of thumb they use in solving problems … The program is designed to solve a problem the way that humans seem to solve it. 帕纳斯厘清了人工智能概念的定义混淆问题{4}：当下业界通用两套完全不同的人工智能定义。AI-1：利用计算机解决以往仅靠人类智能才能处理的问题。AI-2：采用启发式、基于规则的特定编程技术；该思路会研究行业专家解决问题的经验与通用准则，让程序模仿人类专家的解题逻辑。

The first definition has a sliding meaning … Something can fit the definition of AI-1 today but, once we see how the program works and understand the problem, we will not think of it as AI any more … Unfortunately I cannot identify a body of technology that is unique to this field … Most of the work is problem-specific, and some abstraction or creativity is required to see how to transfer it. 第一层定义具备动态边界：某套程序当下符合 AI-1 定义，但一旦人类完全理解其运行逻辑与问题原理，就不再将其视作人工智能。遗憾的是，不存在专属于人工智能领域的通用底层技术；多数算法方案高度绑定特定业务场景，很难抽象复用。

I agree completely with this critique. The techniques used for speech recognition seem to have little in common with those used for image recognition, and both are different from those used for expert systems. I have a hard time seeing how image recognition, for example, will make any appreciable difference in programming practice. The same is true of speech recognition. The hard thing about building software is deciding what one wants to say, not saying it. No facilitation of expression can give more than marginal gains. 上述观点具备充分合理性。语音识别、图像识别、专家系统的底层技术几乎无共通性。以图像识别为例，很难看出该技术能对日常编程工作产生实质性改善。语音识别同理。软件开发真正的难点是明确需要实现的逻辑，而非把逻辑编写为代码。任何简化代码编写的工具，仅能带来小幅效率提升。

4.4 Expert Systems

4.4 专家系统

The most advanced part of the artificial intelligence art, and the most widely applied, is the technology for building expert systems. Many software scientists are hard at work applying this technology to the software-building environment {5}{6}. What is the concept, and what are the prospects? 人工智能领域发展最成熟、落地最广泛的分支是专家系统构建技术。大量软件工程研究者正致力于将专家系统技术应用于软件开发环境{5}{6}。下文阐释专家系统核心原理与应用前景。

An expert system is a program containing a generalized inference engine and a rule base, designed to take input data and assumptions and explore the logical consequences through the inferences derivable from the rule base, yielding conclusions and advice, and offering to explain its results by retracing its reasoning for the user. The inference engines typically can deal with fuzzy or probabilistic data and rules in addition to purely deterministic logic. 专家系统由通用推理引擎与规则库组成：接收输入数据与预设条件，基于规则库推导逻辑结论，输出分析建议，并可回溯推理路径向用户解释结果来源。推理引擎除处理确定逻辑外，还支持模糊、概率类数据与规则。

Such systems offer some clear advantages over programmed algorithms for arriving at the same solutions to the same problems: • Inference engine technology is developed in an application-independent way, and then applied to many uses. One can justify much more effort on the inference engines. Indeed, that technology is well advanced. • The changeable parts of the application-peculiar materials are encoded in the rule base in a uniform fashion, and tools are provided for developing, changing, testing, and documenting the rule base. This regularizes much of the complexity of the application itself. 对比传统固定算法，专家系统处理同类问题具备明确优势：• 推理引擎与业务场景解耦，可复用至各类场景；开发者可投入大量资源打磨通用推理引擎，该技术现已发展成熟。• 业务独有的可变逻辑统一存入规则库，配套工具支持规则编写、修改、测试、文档化，标准化了业务侧的大量复杂逻辑。

Edward Feigenbaum says that the power of such systems does not come from ever-fancier inference mechanisms, but rather from ever-richer knowledge bases that reflect the real world more accurately. I believe the most important advance offered by the technology is the separation of the application complexity from the program itself. 爱德华·费根鲍姆提出：专家系统的核心能力不在于复杂推理机制，而在于贴合真实业务、内容完备的知识库。该技术最大突破，是将业务复杂逻辑与底层程序代码解耦。

How can this be applied to the software task? In many ways: suggesting interface rules, advising on testing strategies, remembering bug-type frequencies, offering optimization hints, etc. 该技术可多维度赋能软件开发：推荐接口规范、提供测试策略建议、统计高频缺陷类型、给出代码优化提示等。

Consider an imaginary testing advisor, for example. In its most rudimentary form, the diagnostic expert system is very like a pilot’s checklist, fundamentally offering suggestions as to possible causes of difficulty. As the rule base is developed, the suggestions become more specific, taking more sophisticated account of the trouble symptoms reported. One can visualize a debugging assistant which offers very generalized suggestions at first, but as more and more system structure is embodied in the rule base, becomes more and more particular in the hypotheses it generates and the tests it recommends. Such an expert system may depart most radically from the conventional ones in that its rule base should probably be hierarchically modularized in the same way the corresponding software product is, so that as the product is modularly modified, the diagnostic rule base can be modularly modified as well. 举一个虚拟测试辅助专家系统为例。最简形态的诊断专家系统类似飞行员检查清单，仅针对故障给出潜在诱因建议。随着规则库完善，系统可结合故障现象给出更精准的定位建议。设想一套调试辅助系统：初期仅给出宽泛排查思路；当规则库录入完整系统架构后，可生成精准故障假设与针对性测试方案。该调试辅助系统与传统专家系统最大区别在于：规则库与配套软件采用一致的分层模块化结构，软件模块迭代修改时，对应诊断规则可同步模块化更新。

The work required to generate the diagnostic rules is work that will have to be done anyway in generating the set of test cases for the modules and for the system. If it is done in a suitably general manner, with a uniform structure for rules and a good inference engine available, it may actually reduce the total labor of generating bring-up test cases, as well as helping in life-long maintenance and modification testing. In the same way, one can postulate other, probably many and probably simple, advisors for the other parts of the software construction task. 编写诊断规则所需的梳理工作，本就是模块与系统测试用例编写的必经流程。若以通用化思路编写规则、搭配标准化规则结构与成熟推理引擎，反而能减少测试用例编写总工作量，同时支撑软件全生命周期的维护与迭代测试。同理，可搭建大量轻量化专家辅助工具，覆盖软件开发全流程各环节。

Many difficulties stand in the way of the early realization of useful expert advisors to the program developer. A crucial part of our imaginary scenario is the development of easy ways to get from program structure specification to the automatic or semiautomatic generation of diagnostic rules. Even more difficult and important is the two-fold task of knowledge-acquisition: finding articulate, self-analytical experts who know why they do things; and developing efficient techniques for extracting what they know and distilling it into rule bases. The essential prerequisite for building an expert system is to have an expert. 落地实用的开发辅助专家系统仍存在诸多阻碍。前文设想的工具落地关键难点：如何基于软件架构设计，全自动或半自动生成诊断规则。更核心、难度更高的是知识获取双重难题：找到能清晰复盘自身设计思路的资深专家；搭建高效方法提炼专家经验，整理录入规则库。搭建专家系统的基础前提是存在对应领域的资深专家。

The most powerful contribution of expert systems will surely be to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers. This is no small contribution. The gap between the best software engineering practice and the average practice is very wide -perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important. 专家系统最大价值，是将顶尖开发者的经验沉淀为工具，赋能经验不足的程序员。该提升具备重大意义。软件工程领域顶尖实践与普通开发实践差距极大，差距幅度甚至超过其他所有工程学科。能够标准化推广优秀开发实践的工具具备重大意义。

4.5 “Automatic” Programming

4.5 “自动编程”

For almost 40 years, people have been anticipating and writing about “automatic programming”, the generation of a program for solving a problem from a statement of the problem specifications. Some today write as if they expected this technology to provide the next breakthrough {7}. 近四十年来，业界持续畅想、研究“自动编程”：仅输入业务需求描述，系统自动生成完整求解程序。当年不少研究者认为自动编程将成为下一项颠覆性技术突破{7}。

Parnas {8} implies that the term is used for glamor and not semantic content, asserting, In short, automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer. 帕纳斯{8}提出，“自动编程”只是噱头词汇，无实质全新定义，他指出：简言之，所谓自动编程，只是“使用比当前更高级的编程语言开发”的美化说法。

He argues, in essence, that in most cases it is the solution method, not the problem, whose specification has to be given. 核心观点：绝大多数场景下，开发者必须描述实现方案，而非仅描述问题本身。

One can find exceptions. The technique of building generators is very powerful, and it is routinely used to good advantage in programs for sorting. Some systems for integrating differential equations have also permitted direct specification of the problem, and the system assessed the parameters, chose from a library of methods of solution, and generated the programs. 但存在少数特例。代码生成器技术效果显著，排序类程序开发已常态化使用该方案。部分微分方程求解系统支持仅输入问题描述，系统自动评估参数、从算法库匹配求解方案并生成代码。

These applications have very favorable properties: • The problems are readily characterized by relatively few parameters. • There are many known methods of solution to provide a library of alternatives. • Extensive analysis has led to explicit rules for selecting solution techniques, given problem parameters. 这类可实现自动生成的场景具备三项共性特征：• 问题可通过少量参数完整定义。• 存在成熟、可复用的标准化求解算法库。• 已有完善理论，可根据参数明确匹配最优求解方案。

It is hard to see how such techniques generalize to the wider world of the ordinary software system, where cases with such neat properties are the exception. It is hard even to imagine how this breakthrough in generalization could conceivably occur. 这套技术很难通用到绝大多数常规软件系统，满足上述特征的业务场景只是少数特例。甚至难以设想，未来如何实现该技术的大规模通用化突破。

4.6 Graphical Programming

4.6 图形化编程

A favorite subject for Ph.D. dissertations in software engineering is graphical, or visual, programming, the application of computer graphics to software design {9}{10}. Sometimes the promise of such an approach is postulated from the analogy with VLSI chip design, where computer graphics plays so fruitful a role. Sometimes the approach is justified by considering flowcharts as the ideal program design medium, and providing powerful facilities for constructing them. 图形化（可视化）编程是当年软件工程博士论文热门选题，核心是将计算机图形技术应用于软件设计{9}{10}。支持者常类比超大规模集成电路芯片设计：图形工具在芯片设计领域成效显著，因此认为软件图形化设计同样具备巨大潜力。另一类支撑观点认为流程图是理想设计载体，只需搭建完善的流程图绘制工具即可简化开发。

Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will. 但相关研究至今未产出具备说服力、更谈不上颠覆性的成果。该方向不会出现重大突破。

In the first place, as I have argued elsewhere {11}, the flowchart is a very poor abstraction of software structure. Indeed, it is best viewed as Burks, von Neumann, and Goldstine’s attempt to provide a desperately needed high-level control language for their proposed computer. In the pitiful, multi-page, connection-boxed form to which the flowchart has today been elaborated, it has proved to be essentially useless as a design tool- programmers draw flowcharts after, not before, writing the programs they describe. 首先，在其他论述中已经说明{11}：流程图对软件结构的抽象表达能力极差。流程图最初是伯克斯、冯·诺依曼、戈德斯坦为早期计算机设计的简易高层控制逻辑表达工具。如今流程图演变为多页、大量连线框的复杂形式，已基本丧失设计辅助价值：开发者都是写完代码后补画流程图，而非先画图再编码。

Secondly, the screens of today are too small, in pixels, to show both the scope and the resolution of any serious detailed software diagram. The so-called “desktop metaphor” of today’s workstation is instead an “airplane-seat” metaphor. Anyone who has shuffled a lap full of papers while seated in coach between two portly passengers will recognize the difference – one can see only a very few things at once. The true desktop provides overview of and random access to, a score of pages. Moreover, when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. The hardware technology will have to advance quite substantially before the scope of our scopes is sufficient to the software design task. 其次，当年显示器像素尺寸有限，无法同时完整展示大型软件结构图的全局视图与细节信息。当时工作站标榜的“桌面可视化”，实际体验更像“飞机狭小座位”。乘坐经济舱、两侧乘客体型宽大时，只能同时翻看少量纸张，体验和宽大桌面完全不同，工作站可视化界面同理。真实桌面可同时平铺十几份图纸，全局浏览、随意查阅。此外，开发者灵感迸发时，常会把图纸铺在地面获取更大展示空间。硬件显示技术需要大幅迭代，才能满足软件复杂结构图的可视化展示需求。

More fundamentally, as I have argued above, software is very difficult to visualize. Whether one diagrams control flow, variable scope nesting, variable cross-references, data flow, hierarchical data structures, or whatever, one feels only one dimension of the intricately interlocked software elephant. If one superimposes all the diagrams generated by the many relevant views, it is difficult to extract any global overview. The VLSI analogy is fundamentally misleading – a chip design is a layered two-dimensional object whose geometry reflects its essence. A software system is not. 更深层的核心原因前文已阐述：软件本身难以可视化。无论绘制控制流、变量作用域嵌套、变量关联、数据流、分层数据结构，都只能展现软件复杂逻辑的单一维度。即便叠加全部维度视图，也很难梳理出系统全局逻辑。芯片设计的类比存在根本性误导：芯片是分层二维实体，几何布局直接对应其内在构成；软件系统并非如此。

4.7 Program Verification

4.7 程序形式化验证

Much of the effort in modern programming goes into testing and the repair of bugs. Is there perhaps a silver bullet to be found by eliminating the errors at the source, in the system design phase? Can both productivity and product reliability be radically enhanced by following the profoundly different strategy of proving designs correct before the immense effort is poured into implementing and testing them? 现代软件开发大量工时消耗在测试与缺陷修复工作上。是否存在银弹，能在设计阶段从根源杜绝缺陷？是否可以采用全新思路：在编码、大规模测试前，通过数学证明验证设计正确性，从而大幅提升效率与可靠性？

I do not believe we will find the magic here. Program verification is a very powerful concept, and it will be very important for such things as secure operating system kernels. The technology does not promise, however, to save labor. Verifications are so much work that only a few substantial programs have ever been verified. 形式化验证并非万能方案。程序形式化验证是极具价值的理论，在安全操作系统内核等关键场景不可或缺。但该技术无法大幅节省开发工时。形式化验证工作量极大，历史上仅有少量大型程序完成完整验证。

Program verification does not mean error-proof programs. There is no magic here, either. Mathematical proofs also can be faulty. So whereas verification might reduce the program-testing load, it cannot eliminate it. 形式化验证不代表程序零缺陷，不存在绝对可靠的魔法手段。数学证明过程本身也可能出现推导错误。因此形式化验证仅能减轻测试工作量，无法彻底替代测试。

More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification. 更关键的局限：即便完美完成程序验证，也仅能证明代码符合既定需求文档。软件开发最难的环节是产出完整、无矛盾的需求定义，软件开发大量工作量，实际都消耗在修正需求偏差上。

4.8 Environments and Tools

4.8 开发环境与工具链

How much more gain can be expected from the exploding researches into better programming environments? One’s instinctive reaction is that the big-payoff problems were the first attacked, and have been solved: hierarchical file systems, uniform file formats so as to have uniform program interfaces, and generalized tools. Language-specific smart editors are developments not yet widely used in practice, but the most they promise is freedom from syntactic errors and simple semantic errors. 当下大量研究投入优化开发环境，这类方案还能带来多大效率提升？直观判断：收益最高的基础问题早已被解决：分层文件系统、统一文件格式标准化程序接口、通用基础工具。语言专属智能编辑器尚未大规模普及，其上限仅能规避语法错误与简单语义错误。

Perhaps the biggest gain yet to be realized in the programming environment is the use of integrated database systems to keep track of the myriads of details that must be recalled accurately by the individual programmer and kept current in a group of collaborators on a single system. 开发环境尚存的最大优化空间，是集成数据库统一管理海量项目细节：支撑开发者精准查阅、团队同步更新项目全量信息。

Surely this work is worthwhile, and surely it will bear some fruit in both productivity and reliability. But by its very nature, the return from now on must be marginal. 工具环境优化具备研究价值，能够小幅提升开发效率与软件可靠性。但受其本身属性限制，后续收益只能是边际小幅提升。

4.9 Workstations

4.9 高性能工作站

What gains are to be expected for the software art from the certain and rapid increase in the power and memory capacity of the individual workstation? Well, how many MIPS can one use fruitfully? The composition and editing of programs and documents is fully supported by today’s speeds. Compiling could stand a boost, but a factor of 10 in machine speed would surely leave think-time the dominant activity in the programmer’s day. Indeed, it appears to be so now. 个人工作站算力、内存持续快速提升，能为软件开发带来多大改善？开发者能有效利用的算力存在上限。当年工作站算力已完全满足代码、文档编辑需求。编译速度虽有提升空间，但即便机器运算速度提升 10 倍，开发者每日大部分工时依旧消耗在逻辑思考上。当年的开发场景已然是该现状。

More powerful workstations we surely welcome. Magical enhancements from them we cannot expect. 高性能工作站值得推广，但不能指望其带来颠覆性效率提升。

5. PROMISING ATTACKS ON THE CONCEPTUAL ESSENCE

5 直击软件概念内在构成的可行优化路径

Even though no technological breakthrough promises to give the sort of magical results with which we are so familiar in the hardware area, there is both an abundance of good work going on now, and the promise of steady, if unspectacular progress. 尽管不存在类似硬件领域的颠覆性万能技术，但当下已有大量成熟研究方向，能够实现稳定、渐进式的效率提升。

All of the technological attacks on the accidents of the software process are fundamentally limited by the productivity equation: [time\\ of\\ task =\\sum_{i}( frequency ){i} \\times( time ){i}] If, as I believe, the conceptual components of the task are now taking most of the time, then no amount of activity on the task components that are merely the expression of the concepts can give large productivity gains. 所有针对偶然性难题的技术优化，收益上限都受如下效率公式约束：[任务总耗时 = \\sum_{i}(操作频次)_{i} \\times(单次耗时)]若概念梳理环节占用大部分工时，那么仅优化代码编写这类概念表达工作，无法实现大幅效率提升。

Hence we must consider those attacks that address the essence of the software problem, the formulation of these complex conceptual structures. Fortunately, some of these are very promising. 因此我们必须聚焦直击软件内在构成的方案，也就是优化复杂概念结构的设计流程。所幸存在多条具备落地价值的优化路径。

5.1 Buy versus Build

5.1 采购现成软件，而非从零自研

The most radical possible solution for constructing software is not to construct it at all. 减少开发工作量最彻底的方案：尽可能不开发软件。

Every day this becomes easier, as more and more vendors offer more and better software products for a dizzying variety of applications. While we software engineers have labored on production methodology, the personal computer revolution has created not one, but many, mass markets for software. Every newsstand carries monthly magazines which, sorted by machine type, advertise and review dozens of products at prices from a few dollars to a few hundred dollars. More specialized sources offer very powerful products for the workstation and other Unix markets. Even software tools and environments can be bought off-the-shelf. I have elsewhere proposed a marketplace for individual modules. 如今软件厂商提供的商用产品品类持续丰富，覆盖海量业务场景，外购方案落地门槛不断降低。软件工程从业者持续钻研开发方法论的同时，个人计算机浪潮催生了多个大规模软件消费市场。报刊亭按月发行分设备品类的软件期刊，刊登数十款软件评测与广告，售价从数美元至数百美元不等。专业渠道为工作站、Unix 生态提供高性能商用软件。就连开发工具、一体化环境都有标准化成品可采购。其他论述中提出，可搭建标准化软件组件交易市场。

Any such product is cheaper to buy than to build afresh. Even at a cost of one hundred thousand dollars, a purchased piece of software is costing only about as much as one programmer-year. And delivery is immediate! Immediate at least for products that really exist, products whose developer can refer the prospect to a happy user. Moreover, such products tend to be much better documented and somewhat better maintained than homegrown software. 外购成品软件的综合成本，低于从零自研。即便软件采购价高达十万美元，成本也仅约等于一名程序员一年人力成本。成品交付周期极短；前提是产品成熟，厂商可提供真实落地客户案例。商用成品软件配套文档更完善，版本维护迭代也优于企业自研内部系统。

The development of the mass market is, I believe, the most profound long-run trend in software engineering. The cost of software has always been development cost, not replication cost. Sharing that cost among even a few users radically cuts the per-user cost. Another way of looking at it is that the use of n copies of a software system effectively multiplies the productivity of its developers by n. That is an enhancement of the productivity of the discipline and of the nation. 大众商用软件市场发展是影响深远的长期发展趋势。软件成本核心是研发成本，复制分发成本几乎可忽略。研发成本由多名用户分摊后，单用户使用成本大幅下降。换个角度理解：一套软件卖给 n 个客户，等价于开发者的产出效率放大 n 倍。这会提升整个行业乃至国家层面的软件产出效率。

The key issue, of course, is applicability. Can I use an available off-the-shelf package to do my task? A surprising thing has happened here. During the '50’s and '60’s, study after study showed that users would not use off-the-shelf packages for payroll, inventory control, accounts receivable, etc. During the '80’s, we find such packages in high demand and widespread use. What has changed? 外购方案的核心制约是适配性：商用成品能否满足自身业务需求？行业出现了一个显著变化。50、60 年代多项调研显示：企业不会采购薪资、库存、应收款管理等商用软件，需求定制化程度过高。但到 80 年代，这类商用管理软件需求暴涨、普及落地。变化源于何处？

Not really the packages. They may be somewhat more generalized and somewhat more customizable than formerly, but not much. Not really the applications, either. If anything, the business and scientific needs of today are more diverse, more complicated than those of twenty years ago. 并非软件本身大幅进化：成品通用性、可配置性仅有小幅提升。业务需求也没有简化，反而比二十年前更多元、更复杂。

The big change has been in the hardware/software cost ratio. The buyer of a two-million dollar machine in 1960 felt that he could afford $ 250,000 more for a customized payroll program, one that slipped easily and non-disruptively into the computer-hostile social environment. The buyer of a $ 50,000 dollar office machine today cannot conceivably afford a customized payroll program; so he adapts his payroll procedure to the packages available. Computers are now so commonplace, if not yet so beloved, that the adaptations are accepted as a matter of course. 核心变化是软硬件成本占比发生反转。1960 年企业采购两百万美元硬件设备，愿意额外投入二十五万美元定制薪资系统，适配原有传统业务流程。企业采购五万美元办公设备后，无力承担定制开发成本，只能调整自身业务流程适配商用软件。计算机普及后，企业愿意主动调整业务流程适配标准化软件。

There are dramatic exceptions to my argument that the generalization of the software packages has changed little over the years: electronic spreadsheets and simple database systems. These powerful tools, so obvious in retrospect and yet so late appearing, lend themselves to myriads of uses, some quite unorthodox. Articles and even books now abound on how to tackle unexpected tasks with the spreadsheet. Large numbers of applications that would formerly have been written as custom programs in Cobol or Report Program Generator are now routinely done with these tools. 商用软件通用性提升有限，但电子表格、简易数据库是重大特例。这类工具能力强大，事后看价值显而易见，但面世时间较晚，可适配海量非常规业务场景。当年已有大量文章、书籍讲解如何用电子表格解决各类非常规业务需求。以往需要用 Cobol、报表生成工具定制开发的大量业务，如今直接通过电子表格、简易数据库完成。

Many users now operate their own computers day in and day out on varied applications without ever writing a program. Indeed, many of these users cannot write new programs for their machines, but they are nevertheless adept at solving new problems with them. 大量普通用户日常使用计算机处理各类业务，完全无需编写代码。许多用户不具备编程能力，却能熟练利用标准化工具解决全新业务问题。

I believe the single most powerful software productivity strategy for many organizations today is to equip the computer-naive intellectual workers on the firing line with personal computers and good generalized writing, drawing, file, and spreadsheet programs, and turn them loose. The same strategy, with generalized mathematical and statistical packages and some simple programming capabilities, will also work for hundreds of laboratory scientists. 对多数企业而言，提升软件产出效率最有效的策略：为一线业务人员配备个人电脑与通用文字、绘图、文件、表格工具，由业务人员自主完成简单业务处理。为科研人员配套通用数学、统计工具与简易脚本能力，该策略同样适用。

5.2 Requirements Refinement and Rapid Prototyping

5.2 需求迭代梳理与快速原型

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. 软件开发最困难的单一环节，是精准定义需要开发的系统功能。所有概念梳理工作中，梳理完整详细技术需求难度最高，包含人机交互、硬件对接、第三方软件接口全部场景。需求定义出错，对最终系统的负面影响远超其他环节失误。需求缺陷后期修复成本也是全流程最高的。

Therefore the most important function that the software builder does for his client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. He usually does not know what questions must be answered, and he almost never has thought of the problem in the detail that must be specified. Even the simple answer – “Make the new software system work like our old manual information-processing system” – is in fact too simple. One never wants exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition. 因此软件开发者为客户提供核心价值，是反复挖掘、迭代完善产品需求。客观事实：客户本身无法完整清晰描述自身需求。客户通常不清楚需要明确哪些技术细节，更不会从软件落地视角梳理完整需求细节。即便客户提出简单需求“新系统复刻原有手工业务流程”，该描述也过于笼统。客户实际不会完全照搬旧流程。复杂软件系统具备动态运行逻辑。动态运行效果仅靠文字描述难以想象。因此任何软件项目规划，都必须预留客户与设计者的多轮迭代周期，作为需求定义的标准流程。

I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product he is specifying. 进一步提出观点：即便客户配合软件工程师，在未搭建、试用软件原型前，也不可能完整、精准、无误地定义现代软件产品的全部需求。

Therefore one of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements. 当下极具前景、直击软件内在构成而非表层偶然问题的技术方向，是搭建快速原型工具与流程，将原型验证纳入需求迭代定义环节。

A prototype software system is one which simulates the important interfaces and performs the main functions of the intended system, while not being necessarily bound by the same hardware speed, size, or cost constraints. Prototypes typically perform the mainline tasks of the application, but make no attempt to handle the exceptions, respond correctly to invalid inputs, abort cleanly, etc. The purpose of the prototype is to make real the conceptual structure specified, so that the client can test it for consistency and usability. 软件原型模拟目标系统核心接口与主干功能，无需遵循最终产品的硬件性能、存储、成本约束。原型一般仅实现主干业务流程，不处理异常场景、非法输入、优雅退出等边缘逻辑。原型的核心作用是将抽象需求具象化，让客户直观验证需求逻辑是否自洽、功能是否好用。

Much of present-day software acquisition procedures rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy. Hence they cannot be fixed without fundamental revision, one which provides for iterative development and specification of prototypes and products. 当年多数软件采购流程基于一个假设：可提前完整定义合格系统，招标开发、交付上线。该底层假设存在根本性错误，大量软件采购纠纷都源于此逻辑谬误。必须彻底重构采购流程，将原型迭代、分阶段开发纳入标准流程，才能解决相关问题。

5.3 Incremental Development – Grow, not Build, Software

5.3 增量式开发：软件是逐步生长，而非一次性搭建

I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding. 1958 年，第一次听到朋友用“搭建程序”替代“编写程序”的说法时，内心受到极大触动。这个比喻瞬间拓宽了对软件开发流程的整体认知。“搭建”这一比喻精准且具备极强启发意义。如今普遍认可软件开发和建筑施工存在共通之处，广泛复用相关类比词汇：需求图纸、组件装配、脚手架。

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach. 但“建筑搭建”的比喻已存在局限性，需要更换全新思路。当下软件概念结构过于复杂，无法提前精准定义、一次性无缺陷开发完成，我们必须采用全新开发思路。

Let us turn to nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built. 应当借鉴自然界生物的复杂演化逻辑，而非仅参考人工静态造物。生物的复杂结构令人惊叹。仅人脑的复杂程度就无法完整绘制映射，具备极强运算能力、多元功能、自我防护、自我迭代更新能力。核心规律：生物器官是逐步生长演化，而非一次性搭建完成。

So it must be with our software systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development {12}. That is, the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below. 软件系统开发同理。多年前哈伦·米尔斯提出，所有软件系统都应采用增量式生长开发{12}。核心思路：先搭建可运行空框架，仅调用占位假子程序，无实际业务功能。随后逐步填充功能，依次将假子程序实现为完整逻辑，或调用下层占位桩函数。

I have seen most dramatic results since I began urging this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there. 在软件工程实验室课程中持续推广增量开发，亲眼见证该方法带来巨大项目改善。过去十年，没有任何技术思路能像增量开发一样彻底改变开发实践与产出效果。增量开发需要配套自顶向下设计，软件从顶层框架向下逐层生长完善。该方法便于回退调整，天然适配早期原型搭建。每新增一项功能、每一套应对复杂数据与场景的逻辑，都能基于现有系统有机拓展。

The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build. 该模式对团队士气的提升效果十分惊人。只要拥有一套可运行系统——哪怕功能极简，团队积极性都会大幅高涨。图形软件首次在屏幕渲染出图形时（哪怕只是一个矩形），所有人的工作动力都会翻倍。项目全流程的每个阶段，团队都能持有一套可正常运行的系统。团队用四个月增量迭代产出的系统，复杂度远高于同期一次性搭建开发的成果。

The same benefits can be realized on large projects as on my small ones {13}. 该方案无论小型项目还是大型项目，都能收获同等收益{13}。

5.4 Great Designers

5.4 培养顶尖架构设计者

The central question in how to improve the software art centers, as it always has, on people. 想要提升软件工程整体水平，核心问题自始至终都落在人身上。

We can get good designs by following good practices instead of poor ones. Good design practices can be taught. Programmers are among the most intelligent part of the population, so they can learn good practice. Thus a major thrust in the United States is to promulgate good modern practice. New curricula, new literature, new organizations such as the Software Engineering Institute, all have come into being in order to raise the level of our practice from poor to good. This is entirely proper. 遵循标准化优秀开发规范，就能产出合格设计；优秀设计方法论可以通过教学传授。程序员群体整体智力水平出众，完全有能力掌握规范流程。因此美国当下大力推广现代化软件工程最佳实践：全新专业课程、行业著作、软件工程研究所等机构相继成立，目标是将行业平均开发水准从劣质提升至合格。这类举措完全合理。

Nevertheless, I do not believe we can make the next step upward in the same way. Whereas the difference between poor conceptual designs and good ones may lie in the soundness of design method, the difference between good designs and great ones surely does not. Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge. 但仅靠这套方式，无法实现行业水准的跨越式提升。劣质设计与合格设计的差距来源于设计方法是否严谨规范，但合格设计与顶尖设计的差距绝非如此。顶尖的软件设计只能出自顶尖设计者之手，软件开发本身属于创造性工作。完备的流程规范能够释放创作者的思路，却无法唤醒平庸从业者的创造灵感。

The differences are not minor – it is rather like Salieri and Mozart. Study after study show that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude. 二者的差距悬殊，如同萨列里与莫扎特的天壤之别。多项调研结果表明，顶尖设计者搭建的架构运行速度更快、占用资源更少、逻辑更简洁规整，开发投入的工作量也更低。顶尖人才与普通开发者的产出差距接近一个数量级。

A little retrospection shows that although many fine, useful software systems have been designed by committees and built by multipart projects, those software systems that have excited passionate fans are those which are the products of one or a few designing minds, great designers. Consider Unix, APL, Pascal, Modula, the Smalltalk interface, even Fortran; and contrast with Cobol, PL/I, Algol, MVS/370, and MS-DOS. 回顾行业发展历程不难发现，尽管不少实用优秀软件由委员会统筹、多团队协作完成，但真正收获业界广泛推崇的软件，全都源自一位或少数几位顶尖设计者。例如 Unix、APL、Pascal、Modula、Smalltalk 交互体系，乃至 Fortran；与之形成对比的是 Cobol、PL/I、Algol、MVS/370、MS-DOS 这类由多人委员会主导设计的产品。

Hence, although I strongly support the technology transfer and curriculum development efforts now underway, I think the most important single effort we can mount is to develop ways to grow great designers. 因此，虽然我十分支持当下开展的技术普及与课程建设工作，但行业最核心的投入方向，应当是搭建一套完整体系来培育顶尖设计者。

No software organization can ignore this challenge. Good managers, scarce though they be, are no scarcer than good designers. Great designers and great managers are both very rare. Most organizations spend considerable effort in finding and cultivating the management prospects; I know of none that spends equal effort in finding and developing the great designers upon whom the technical excellence of the products will ultimately depend. 任何软件企业都不能忽视这项任务。优秀管理者本就稀缺，但顶尖设计者的稀缺程度与之持平。顶级设计者与顶级管理者都属于稀缺人才。绝大多数企业会投入大量资源挖掘、储备管理后备人才，却几乎没有企业愿意拿出同等资源发掘、培养决定产品技术上限的架构设计者。

My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded. Not only salary, but the perquisites of recognition – office size, furnishings, personal technical equipment, travel funds, staff support – must be fully equivalent. 我的第一条建议：每家软件企业都必须明确公示，顶尖设计者对企业发展的价值等同于顶尖管理者，二者应当获得同等的培养资源与薪酬回报。不只是薪资，各类荣誉配套资源——办公场地、办公设备、专属研发器材、差旅预算、配套助理团队，都需要完全对等。

How to grow great designers? Space does not permit a lengthy discussion, but some steps are obvious: 如何培育顶尖设计者？受篇幅限制无法展开详述，但核心举措清晰明确：

• Systematically identify top designers as early as possible. The best are often not the most experienced. 尽早系统化发掘潜力设计者，真正的顶尖人才往往并非工龄最长的员工。

• Assign a career mentor to be responsible for the development of the prospect, and keep a careful career file. 为潜力人才配备专属职业导师，全程跟进成长路径，并建立完整成长档案。

• Devise and maintain a career development plan for each prospect, including carefully selected apprenticeships with top designers, episodes of advanced formal education, and short courses, all interspersed with solo design and technical leadership assignments. 为每位潜力人才定制长期成长方案：安排跟随顶尖设计者实习、参与高阶专业进修、短期专题培训，同时穿插独立架构设计、技术负责人实战任务。

• Provide opportunities for growing designers to interact with and stimulate each other. 搭建交流渠道，让潜力设计者互相沟通、碰撞思路。

ACKNOWLEDGEMENTS

致谢

I thank Gordon Bell, Bruce Buchanan, Rick Hayes-Roth, Robert Patrick, and, most especially, David Parnas for their insights and stimulating ideas, and Rebekah Bierly for technical production. 感谢戈登·贝尔、布鲁斯·布坎南、里克·海斯-罗斯、罗伯特·帕特里克，尤其感谢戴维·帕纳斯提供的独到见解与富有启发的观点，同时感谢丽贝卡·比尔利完成文稿排版校对工作。

REFERENCES

参考文献

《无银弹》论断在大模型时代的适用性

一、布鲁克斯两大底层论断

软件四大本质约束：复杂性、适配约束性、易变性、不可可视化，均为软件与生俱来的属性。

二、大模型对偶然性难题与本质性难题的影响

2.1 大模型对偶然性难题的优化

偶然性难题涵盖：语法书写、重复模板代码、基础配置、单元测试编写、文档摘抄、基础调试、语言记忆等机械编码工作。大模型的价值集中于以下方面：

• 自动生成模板代码、补齐函数、编写 SQL、接口模板；
• 自动生成单元、集成测试用例；
• 生成注释、接口文档、运维脚本；
• 快速定位语法类、简单逻辑缺陷，缩短查错耗时；
• 替代大量重复、标准化 CRUD、工具脚本开发。

此类进步与高级语言替代汇编、一体化 IDE 简化编译流程属于同一范畴，仅优化实现环节的附加负担，属于布鲁克斯所预判的"渐进式小幅收益"。行业实测表明：大模型仅能将编码环节效率提升 20%–60%，远未达到数量级跨越。

2.2 四大本质难题的不可消解性

（1）复杂性

软件的复杂度源于业务逻辑、模块依赖的非线性耦合，而非代码书写工作量。

局限：大模型仅能处理局部函数、单文件逻辑，无法掌握跨数十模块、百万行代码库的全局依赖；易生成高耦合、隐藏副作用的代码，放大系统复杂度。部分团队使用 AI 后技术债务增速反而加快。

（2）适配约束性

软件须对接老旧系统、异构第三方、行业法规、定制业务流程，上述外部约束杂乱无章、无统一规律。

局限：大模型仅学习通用开源标准，对企业私有遗留系统、定制协议、内部规范缺乏认知，所给方案大多无法直接实施，仍需人工大量改造适配。

（3）易变性

软件随业务、硬件、政策持续迭代，增量兼容构成主要难点。

局限：大模型擅长从零生成全新代码，不擅长在存量复杂系统上做增量改造；频繁重写逻辑会破坏原有架构一致性，大量 AI 产出代码的长期维护成本极高。

（4）不可可视化

软件逻辑无天然几何载体，多层数据流、控制流无法完整直观展示。

局限：大模型仅能输出文字代码，无法自动生成全局架构视图；复杂系统的设计权衡、隐性约束仍须人类设计者分析沟通。

2.3 需求与概念设计：软件最大工作量所在

布鲁克斯指出：软件开发大部分工时不在写代码，而在明确完整、无矛盾的需求，构建统一概念架构。

大模型的短板：

只要需求与架构这类本质工作仍是主要耗时环节，即便将编码（偶然工作）压缩至零，亦无法实现十倍级生产力提升，与原文公式推导一致。

三、大模型并非银弹：与原文对 AI 预判的一致性

布鲁克斯在 1986 年文中专门分析"自动编程、专家系统、人工智能"，得出结论：AI 仅能辅助编码实现，无法解决概念设计难题。大模型作为该技术路线的升级版，结论不变：

四、原文四条可行路线的当代适用性

布鲁克斯给出的四条直击本质的提升路径，在当代更具指导意义：

五、边界变化

布鲁克斯时代，偶然工作占比更高；如今编译器、IDE、云原生、大模型层层优化后，偶然编码工作量占比持续下降，本质的需求、架构、系统权衡成为绝对工时主体。

此变化进一步强化《无银弹》的结论：即便继续优化编码工具，收益空间亦只会越来越小，行业长期进步只能依靠直击本质的方法（需求迭代、增量架构、高端人才培养）。

六、结论

Reference

• No Silver Bullet – Essence and Accidents of Software Engineering – 1986… https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html
• 【译文】没有银弹－软件工程中的根本和次要问题 – 知乎 https://zhuanlan.zhihu.com/p/699194108
• The-Mythical-Man-Month-zh/docs/ch16.md at main · zhengda/The-Mythical-Man-Month-zh · GitHub https://github.com/zhengda/The-Mythical-Man-Month-zh/blob/main/docs/ch16.md
• ……