没有银弹NoSilverBullet

《没有银弹&＃xff1a;软件工程的本质性与附属性工作》&＃xff08;英语&＃xff1a;No Silver Bullet — Essence and Accidents of Software Engineering&＃xff09;是IBM大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文&＃xff0c;原先是在1986年都柏林IFIP研讨会的一篇受邀论文^[1][2]&＃xff0c;隔年电机电子工程师学会《Computer》也转载了这篇文章&＃xff0c;他们用了几张《伦敦狼人(The Werewolf of London)》之类的电影剧照来当作说明&＃xff0c;^[3]还加上了一段〈终结狼人〉的附注&＃xff0c;用来引出非银弹则不能成功的&＃xff08;现代&＃xff09;传说。该论述中强调由于软件的复杂性本质&＃xff0c;而使真正的银弹^[4]并不存在&＃xff1b;所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。

目录

• 1 摘要^[5]
• 2 问题之所在&＃xff0d;银弹与软件专案
• 3 软件开发的困难
  • 3.1 造成本质性困难的原因
  • 3.2 过去的突破解决了附属性的困难
    • 3.2.1 高级语言
    • 3.2.2 分时技术
    • 3.2.3 统一的开发环境
• 4 查找银弹
• 5 评价反响
  • 5.1 Harel的分析
  • 5.2 Jones的观点
• 6 数据源
  • 6.1 参考文献
  • 6.2 脚注
• 7 参见
• 8 外部链接

[编辑] 摘要^[5]

所有软件创作都包括了本质性工作&＃xff08;essential task&＃xff09;和附属性工作&＃xff08;accidental task&＃xff09;。前者是去创造出一种由抽象的软件实体所组成的复杂概念结构&＃xff0c;后者则是用编程语言来表现这些抽象的实体&＃xff0c;并在某些空间和速度的限制之下&＃xff0c;将程序对应至机器语言。

现在&＃xff0c;若跟本质性的工作相比&＃xff0c;软件工程人员所做的事&＃xff0c;还有多少算是花在附属性的工作上呢&＃xff1f;除非附属性工作要耗费的心力超过全部工作的9/10&＃xff0c;否则就算是将所有的附属性工作降至零&＃xff0c;也无法将整个开发工作的轻松程度提升一个数量级。

以往&＃xff0c;软件生产力的重要进展绝大部分是来自于人为障碍的排除&＃xff0c;像是严苛的硬件限制、难用的编程语言、上机时间&＃xff08;machine time&＃xff09;的不足等等&＃xff0c;这些都是造成附属性工作益发困难的原因。

[编辑] 问题之所在&＃xff0d;银弹与软件专案

佛瑞德·布鲁克斯在〈没有银弹〉^[6][7]中提到&＃xff1a;

在民俗传说里&＃xff0c;所有能让我们充满梦靥的怪物之中&＃xff0c;没有比狼人更可怕的了&＃xff0c;因为它们会突然地从一般人变身为恐怖的怪兽&＃xff0c;因此人们尝试着查找能够奇迹似地将狼人一枪毙命的银弹。

我们熟悉的软件专案也有类似的特质&＃xff08;以一个不懂技术的管理者角度来看&＃xff09;&＃xff0c;平常看似单纯而率直&＃xff0c;但很可能一转眼就变成一只时程延误、预算超支、产品充满瑕疵的怪兽&＃xff0c;所以&＃xff0c;我们听到了绝望的呼唤&＃xff0c;渴望有一种银弹&＃xff0c;能够有效降低软件开发的成本&＃xff0c;就跟电脑硬件成本能快速下降一样。

但是&＃xff0c;我们预见&＃xff0c;从现在开始的十年之内&＃xff0c;将不会看到任何银弹&＃xff0c;无论是在技术上或管理上&＃xff0c;都不会有任何单一的重大突破&＃xff0c;能够保证在生产力、可靠度或简洁性上获得改善&＃xff0c;甚至&＃xff0c;连一个数量级的改善都不会有。

然而&＃xff0c;怀疑并非悲观&＃xff0c;虽然我们预见不会有任何重大的突破&＃xff0c;而且事实上&＃xff0c;我相信发生这种重大突破也不符软件的本质&＃xff0c;但是&＃xff0c;仍然有许多令人振奋的创新正在进行当中&＃xff0c;若能按部就班、持之以恒地予以发展、散布&＃xff0c;并灵活运用的话&＃xff0c;想必应该会得到一个数量级的进展。捷径是不会有的&＃xff0c;但有志者事竟成。

人类能克服疾病的第一步&＃xff0c;就是以细菌说&＃xff08;germ theory&＃xff09;^[8]淘汰了恶魔说&＃xff08;demon theory&＃xff09;^[9]和体液说&＃xff08;humours theory&＃xff09;^[10]&＃xff0c;正是这一步&＃xff0c;带给了人类希望&＃xff0c;粉碎了所有奇迹式的冀望&＃xff0c;告诉人们进步是要靠按部就班、不辞劳苦而来&＃xff0c;得在清洁卫生方面持续不断地投入心血&＃xff0c;养成良好习惯&＃xff0c;才是正道。如今&＃xff0c;我们面对软件工程也是一样。

〈没有银弹〉主张并断言在未来的十年之内&＃xff08;从1986年文章发表后开始计算&＃xff09;&＃xff0c;不会有任何单一的软件工程上的突破&＃xff0c;能够让程序设计的生产力得到一个数量级的提升。不过&＃xff0c;作者认为这个假设现在已不再成立。

假设软件开发的总工作量为10&＃xff0c;其中&＃xff0c;本质性工作占掉1&＃xff0c;附属性工作占掉9&＃xff0c;那么改善附属性工作&＃xff0c;将之消除&＃xff0c;就可以把软件工作量减轻到1&＃xff08;因为附属性工作变成0&＃xff09;&＃xff0c;此时我们可以说&＃xff0c;软件工作开发的轻松程度提升了一个数量级&＃xff08;因为由10进步到1&＃xff0c;差10倍&＃xff09;。

[编辑] 软件开发的困难

布鲁克斯将软件开发的困难分为两类&＃xff0c;这篇经典论文的核心论述通常被解释为复杂的软件工程问题无法靠简单的答案来解决。布鲁克斯相信软件开发真正的困难&＃xff0c;是在于这种概念构造的规格制定、设计和测试&＃xff0c;而并非在孜孜矻矻于它的呈现方式&＃xff0c;以及测试该呈现方式的精确程度。

• 本质性&＃xff08;essence&＃xff09;&＃xff1a;软件本身在概念&＃xff08;conceptual&＃xff09;建构上存先天的困难&＃xff1b;亦即如何从抽象性问题&＃xff0c;发展出具体概念上的解决方案。
• 附属性&＃xff08;accident&＃xff09;&＃xff1a;将概念上的构思施行于电脑上&＃xff0c;所遭遇到的困难。

布鲁克斯提到&＃xff0c;有某些地方已经被附属性&＃xff08;accident&＃xff09;和附属的&＃xff08;accidental&＃xff09;这些字眼给混淆了&＃xff0c;这个字眼是出自于亚里斯多德的古老用法。^[11]就附属的&＃xff08;accidental&＃xff09;的这个字眼而言&＃xff0c;他所指的并不是偶然发生的意思&＃xff0c;也不是意外不幸的意思&＃xff0c;而是比较接近伴随的或次要的意思。

[编辑] 造成本质性困难的原因

布鲁克斯认为&＃xff0c;附加性的困难会随着工具的改善而逐渐淡化&＃xff0c;反而是本质性的困难最难以解决&＃xff0c;因为大部分的活动是发生在人们的脑海里&＃xff0c;缺乏有效的辅助工具。依造布鲁克斯的说法有下列几项&＃xff1a;^[12]

• 复杂性&＃xff08;complexity&＃xff09;&＃xff1a;软件要解决的问题&＃xff0c;通常牵扯到计算步骤&＃xff0c;这是一种人为、抽象化的智能活动&＃xff0c;多半是复杂的。
• 隐匿性&＃xff08;invisibility&＃xff09;&＃xff1a;尚未完成的软件是看不见的&＃xff0c;即使利用图标说明&＃xff0c;也常无法充分呈现其结构&＃xff0c;使得人们在沟通上面临极大的困难。^[13]
• 配合性&＃xff08;conformity&＃xff09;&＃xff1a;在大型软件环境中&＃xff0c;各子系统的接口必须协同一致。由于时间和环境的演变&＃xff0c;要维持这样的一致性通常十分困难。
• 易变性&＃xff08;changeability&＃xff09;&＃xff1a;软件所应用的环境常是由人群、法规、硬件设备、应用领域等&＃xff0c;各因素所汇集而成&＃xff0c;而这些因素皆会快速变化。

[编辑] 过去的突破解决了附属性的困难

[编辑] 高级语言

参见&＃xff1a;汇编语言及机器语言

高级语言达成了什么样的使命呢&＃xff1f;它使程序不再陷入许多原来附属在程序里的复杂性。一支抽象的程序所包含的是一些概念的构造&＃xff1a;函数、数据类型、先后顺序的关系&＃xff0c;以及消息传递的方式&＃xff0c;然而实际上&＃xff0c;与机器码攸关的其实是比特、暂存器、条件、分支、通道、软盘等等。高级语言可以将抽象程序里所必要的构造予以具体化&＃xff0c;并且避免掉所有更低级的东西&＃xff0c;在这种情形下&＃xff0c;它把跟程序内涵一点关系都没有的那一整层复杂性给去除了。

[编辑] 分时技术

参见&＃xff1a;时间片

分时&＃xff08;time-sharing&＃xff09;技术所挑战的是另一个截然不同的难题&＃xff0c;因为分时&＃xff0c;确保了实时性&＃xff0c;使我们得以持续保住脑子里对复杂的概观。分时技术所能贡献的底限也可以直接推算出来&＃xff0c;由于其主要的效用就是缩短系统的反应时间&＃xff0c;当这项时间趋近于零&＃xff0c;并在某一点上跨越了人类所能够察觉到有系统反应时间存在的临界点&＃xff0c;大约是十分之一秒&＃xff0c;低于这个值&＃xff0c;就不会再有任何效益了。

[编辑] 统一的开发环境

参见&＃xff1a;集成开发环境

Unix和Interlisp是第一个得到广泛使用的集成软件开发环境&＃xff0c;并且也被公认已将生产力提升了好几倍。这方面所挑战的附属性难题&＃xff0c;就是借由完整的程序库、统一的文件格式、管道&＃xff08;pipe&＃xff09;和过滤器&＃xff08;filter&＃xff09;&＃xff0c;以促成软件的共用&＃xff0c;于是&＃xff0c;任何概念的构造在理论上都可以调用、传递和运用在另一个对象&＃xff0c;而实务上&＃xff0c;这点也很容易就可以办得到。这方面的突破随后也带动了整个工具软件的发展&＃xff0c;因为每一个新工具只要用的是标准规格&＃xff0c;就可以适用于任何程序。

[编辑] 查找银弹

• Ada和其他高级语言的进展

编程语言Ada是1980年代的一个通用型高级语言。事实上&＃xff0c;Ada不只是反映了在语言概念上的演进&＃xff0c;同时也具体实现了一些助长现代设计与模块化概念的特征&＃xff1b;也许&＃xff0c;Ada的理念才是比Ada语言本身更先进的地方&＃xff0c;这理念就是&＃xff1a;模块化&＃xff08;modularity&＃xff09;、抽象数据类型&＃xff08;abstract data type&＃xff09;、层次结构式结构&＃xff08;hierarchical structure&＃xff09;。

• 面向对象程序设计

相对于当今流行的各种技术&＃xff0c;面向对象程序设计&＃xff08;object-oriented programming&＃xff09;已被许多软件工程的学生寄予了更多的希望&＃xff0c;^[14]Dartmouth 的 Mark Sherman 指出&＃xff0c;有两个不同的概念我们必须小心地加以分辨&＃xff0c;从名称上就可以看出这两个概念的不同&＃xff1a;抽象数据类型和层次结构式类型。后者也被称为类型&＃xff08;class&＃xff09;。所谓抽象数据类型&＃xff0c;其概念就是一个对象的类型应该由一个名称、一组适当的值和一组适当的操作方式来定义&＃xff0c;而不是以它存储的结构来定义&＃xff0c;这部分应该是要被隐藏起来的&＃xff0c;例如Ada的包裹&＃xff08;package&＃xff09;&＃xff08;使用私有类型&＃xff09;或Modula的模块&＃xff08;module&＃xff09;。

• 人工智能
• 专家系统
• 自动化程序设计
• 可视化或图形化程序设计
• 软件的验证
• 环境与工具
• 工作站

[编辑] 评价反响

虽然《人月神话》引发了许多论述&＃xff0c;但争议很少&＃xff0c;倒是〈没有银弹〉引发了不少持相反意见的文章&＃xff0c;包括寄给期刊主编的一些信件&＃xff0c;以及到今天都还在持续出现的一些书函和短评&＃xff0c;这其中有大部分是对‘不会有任何特效药的主张’提出反驳。^[15]

在1990年&＃xff0c;Brad Cox^[16]发表一篇〈银弹存在&＃xff08;There Is a Silver Bullet&＃xff09;〉^[17][18]&＃xff0c;Cox指出采取可再利用&＃xff08;reusable&＃xff09;、可替换组件的方式来对付属于概念本质性部分的问题。Glass、Vessey和Conger在他们1992年的一篇论文中就指出&＃xff0c;有充分的证据显示&＃xff0c;对银弹这种没有意义的研究仍尚未停止。^[19]

[编辑] Harel的分析

David Harel在1992年的一篇文献〈咬紧银弹&＃xff08;Biting the Silver Bullet&＃xff09;〉^[20]中&＃xff0c;对已经发表的〈没有银弹〉进行非常仔细的分析。^[21]Harel认为〈没有银弹〉和1984年Parnas〈战略防御系统软件面面观〉^[22]这两篇都写得太过于绝望了&＃xff0c;于是他就针对这一点来阐述较为光明的一面&＃xff0c;他的文章还用了个副标题是“让系统开发走向一个光明的未来”。

就Harvel的认知&＃xff0c;他认为造成〈没有银弹〉悲观的原因有三点&＃xff1a;

• 本质性和附属性的二分法。
• 对每一个可能的银弹采取个别单独评论的方式。
• 只预测10年&＃xff0c;这对“预期任何重大的突破”而言&＃xff0c;并没有足够长的时间。

Harvel更提出了一项假想实验&＃xff0c;他假定〈没有银弹〉的主张不变&＃xff0c;只是发表的时间换做是在1952年&＃xff0c;而非1986年。他这时用的是归谬法&＃xff08;reducto ad absurdum&＃xff09;^[23]&＃xff0c;用来反驳自附属性中切分出本质性的作法。

[编辑] Jones的观点

Caper Jones曾提出一个敏锐的见解&＃xff0c;这个见解最初是写在一连串非正式的纪录中&＃xff0c;后来出现在书上&＃xff0c;几个与布鲁克斯通信的朋友也提到过。〈没有银弹〉就如同大部分的论文一般&＃xff0c;都把焦点集中在生产力&＃xff0c;也就是软件每单位的输入成本能得到多少输出效果。Jones则表示&＃xff1a;“把重点放在品质上&＃xff0c;生产力将随之而来。”^[24][25]他认为&＃xff0c;只要是成本过高和时程落后的专案&＃xff0c;都耗费了非常多的额外时间和工作在查找并修正规格、设计、实现中的错误。Jones并提出数据佐证&＃xff0c;缺乏有系统的品质控制与发生时程落后的灾难&＃xff0c;这两者之间有强烈的相关性。

Caper Jones相信&＃xff0c;两份同等的Cobol程序分别花10年编写&＃xff0c;但其中一份使用结构化的方法&＃xff0c;另一份则否&＃xff0c;那么所得到的效果将相差3倍。

[编辑] 数据源

[编辑] 参考文献

1. Brooks, Fred P.. No Silver Bullet — Essence and Accident in Software Engineering. Proceedings of the IFIP Tenth World Computing Conference. 1986: 1069–1076.
2. Brooks, Fred P.. No Silver Bullet — Essence and Accidents of Software Engineering. IEEE Computer. April 1987, 20 (4): 10–19.
3. Frederick P. Brooks, Jr.; 译者&＃xff1a;钱一一. 人月神话&＃xff1a;软件专案管理之道. 台北市: 经济新潮社. 2004-04-01. ISBN 986-7889-18-5 &＃xff08;正体中文&＃xff09;.

[编辑] 脚注

1. ^ IFIP Congress 1986: Dublin, Ireland
2. ^ Brooks, F. P.,“No silver bullet — essence and accidents of software engineering,”in Information Processing 86, H. J. Kugler, ed. Amsterdam: Elsevier Science (North Holland), 1986, pp. 1069-1076.
3. ^ Brooks, F. P.,“No silver bullet — essence and accidents of software engineering,”Computer 20, 4(April, 1987),pp. 10-19.
4. ^ 欧美古老传说中使用银子弹(silver bullet)可以杀死吸血鬼、狼人或怪兽&＃xff1b;银子弹引申为解决问题的有效方法
5. ^ 这篇标题为〈没有银弹〉的文章出自于Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, pp.1069-76.由H. J. Kugler所编辑。
6. ^ F. P. Brooks,“No Silver Bullet Essence and Accidents of Software Engineering,”Computer, Vol. 20, pp. 10-19, 1987.
7. ^ 编者钱一一译注&＃xff1a;传说在月圆之夜&＃xff0c;狼人就会从普通人兽化成狼&＃xff0c;变成可怕的怪兽&＃xff0c;对付狼人得用银制的子弹贯穿它的心脏。为什么要用银弹&＃xff1f;因为银被视为与月亮同体&＃xff0c;具有法力&＃xff0c;所以银弹是杀死狼人的“必杀技”。
8. ^ 细菌说&＃xff1a;由法国微生物学家巴斯德&＃xff08;Louis Pasteur, 1822&＃xff5e;1895&＃xff09;开创&＃xff0c;发现疾病是由细菌感染而来。
9. ^ 恶魔说&＃xff1a;生病是因为恶魔作怪&＃xff0c;或者是做错事&＃xff0c;触怒了恶魔。
10. ^ 体液说&＃xff1a;人体流着四种体液&＃xff0c;血液&＃xff08;blood&＃xff09;、黏液&＃xff08;phlegm&＃xff09;、胆汁&＃xff08;choler&＃xff09;、黑胆汁&＃xff08;black bile&＃xff09;&＃xff0c;这四种体液各有不同的属性&＃xff0c;决定了人的性情、脾气。生病是因为这四种体液的比例不均衡所致。
11. ^ ‘根据亚里斯多德&＃xff08;Aristotle&＃xff09;和士林哲学&＃xff08;Scholastic philosophy&＃xff09;的说法&＃xff0c;附属性是一种不属于事物根本或必要的性质&＃xff0c;而是其他原因造成的影响才产生出来的性质。’Webster&＃39;s New International Dictionary of the English Language, 2d ed., Springfield, Mass.: G. C. Merriam, 1960.
12. ^ 郑炳强. 软件工程&＃xff1a;从实务出发&＃xff08;Software Engineering: A Perspective from Practices&＃xff09;. 智胜文化事业有限公司. 2007. ISBN 978-957-729-659-7.
13. ^ Parnas, D. L.,“Designing software for ease of extension and contraction.”
    IEEE Trans. on SE,5,2(March, 1979),pp. 128-138
14. ^ Booch, G.,“Object-oriented design,”in Software Engineering with Ada.
    Menlo Park, Calif.: Benjamin/Cummings, 1983.
15. ^ 有些来信与回应刊登在1987年7月份的IEEE《Computer》。虽然没有银弹并未得奖&＃xff0c;但Bruce M. Skwiersky对它的评论获选为1988年《Computer Reviews》的最佳评论&＃xff0c;这份奖项以及该评论被公布并转E. A. Weiss,“Editrial”Computing Reviews (June, 1989),pp.283-284.评论中得有重大错误&＃xff1a;“六倍”应该为“10^6”
16. ^ Brad Cox也是软件的大师级人物&＃xff0c;“软件IC”一词就是他提出来的。
17. ^ Brad Cox. http://virtualschool.edu/cox/pub/NoSilverBulletRevisted/. American Programmer Journal. 1995年11月 [2012-07-10查阅] &＃xff08;英文&＃xff09;. "In one of the most influential books of this era, The Mythical Man-month, Dr. Fred Brooks observed that adding more people to a late software project only seems to make matters worse. And in an equally influential article, No Silver Bullet; Essence and Accidents of Software Engineering, he argued that the difficulties are inevitable, arising from software&＃39;s inescapable essence, as distinct from accident; something we&＃39;re doing wrong in producing it."
18. ^ Cox, B. J.,“There is a silver bullet,”Byte (Oct., 1990),pp.209-218.
19. ^ Glass, R. L., and S. A. Conger,“Research Software tasks: Intellectual or clerical?”Information and Management, 23, 4 (1992),pp.183-192.
20. ^ David Harel. Biting the Silver Bullet: Toward Brighter Future for System Development. 1992年 [2012-07-10查阅] &＃xff08;英文&＃xff09;. "This article was triggered by those of Brooks and Parnas. It is not a rebuttal. Indeed, I agree with most of the specific points made in both papers. Instead, the goal of this article is to illuminate the brighter side of the coin, emphasizing developments in the field that were too recent or immature to have influenced Brooks and Parnas when they wrote their manuscripts."
21. ^ Harel, D.,“Biting the silver bullet: Toward a brighter future for system development,”Computer (Jan., 1992),pp.8-20.
22. ^ Parnas, D. L.,“Software aspects of strategic defense systems,”Communications of the ACM,28,12(Dec., 1985),pp. 1326-1335.
23. ^ 编者钱一一译注&＃xff1a;“归谬法”&＃xff1a;由q出发&＃xff0c;推导出逻辑结果r&＃xff0c;如果r是矛盾的&＃xff0c;那么q就被否定掉。
24. ^ Jones, C., Assessment and Control of Software Risks. Englewood Cliffs, N. J.: Prentice-Hall, 1994.P.619.
25. ^ T.Caper Jones. Assessment and Control of Software Risks. Prentice Hall. 1993-12-17 [2012-07-12察阅]. ISBN 978-0137414062 &＃xff08;英文&＃xff09;.

[编辑] 参见

• 佛瑞德·布鲁克斯
• 人月神话
• 软件危机
• 狼人

[编辑] 外部链接

• &＃xff08;英文&＃xff09; No Silver Bullet: Essence and Accidents of Software Engineering, by Frederick P. Brooks, Jr.
• &＃xff08;西班牙文&＃xff09; No hay balas de plata: Lo esencial y lo accidental en la Ingeniería del Software, by Frederick P. Brooks, Jr.
• &＃xff08;简体中文&＃xff09; 论银弹的存在
• &＃xff08;简体中文&＃xff09; 从没有银弹到银弹加工场