引子
（一年前我写作此文，实在是因为看不惯对于软件技术进步、软件技术革新，国内多少年来总有一些人老是热衷于喊世界上“没有银弹”，全以为自己对软件科技看穿了、看透了（他们真读懂了《人月神话》？），便喜欢对别人的埋头苦干冷嘲热讽。在这些人眼里，“没有银弹”和“软件工程无用论”是联系在一起的。既然没有银弹，软件工程对于所谓的“根本问题”无能为力，那么我们与美欧软件的差距也就没有什么了不起的，于是乎可以心安理得继续安稳地过阿 Q 的日子。据我研究，布教授并没有对“银弹”作出准确、科学的定义，对于什么是布氏“银弹”至少有三种不同的解释，而我们也很难界定到底什么是“单一”的技术——世界上许多东西是可以分解的。依我看，银弹当然是有的。世界上有 60 亿人，又有几个人能攀上珠穆朗玛峰呢？抱着“没有银弹”的观念不放，止步不前、因循守旧，恰恰是部分中国软件人（当然是落后者）一种无能的表现。- 2006.6.30）
No Silver Bullet，这个世界软件工程界最著名的论断，出自美国 1999 年图灵奖得主、世界软件工程界的先驱、权威和元老——费雷德里克·布鲁克斯博士、教授，怎么可能出错呢？的确，这两年来随着《人月神话》中文版、影印版陆续在国内的引进、翻译、出版，以及随之而来的造势和鼓噪，如今“没有银弹”这个时髦的舶来品已几乎成为满天飞的口水词，被 IT 界的一些人天天挂在嘴上，“这个不是银弹，那个不是银弹”,“OOAD 不是银弹，UML 不是银弹，用例不是银弹，RUP 不是银弹，MDA 不是银弹，软件工程也不是银弹……”凡此种种，举不胜举。布氏的没有银弹说（NSB）在人们眼里就好象是可随身携带的万精油、万能膏，只有能找到地方，贴上一剂准保管用。
可事实果真如此吗？布氏银弹到底是什么，现在是不是像大家普遍所认为的那样没有银弹，为什么说有银弹,为什么说布氏银弹没有实际意义,老布的真实意图又是什么？请看下文分解。
动机
最近在一次闲谈中，向一位圈内朋友询问他对国内软件工程现状和未来发展的看法。他是这方面的活跃分子，本以为会听到他一番踌躇满志的表达，却没想到他摇摇头，我问他怎么了，他说“软件工程在国内已经被搞臭了”，所以现在他在外面搞活动，也不敢声张，不敢跟软件工程沾边了。他的这一番话完全出乎我的意料，着实令我吃了一惊！是啊，软件工程无用论和虚无论在中国可谓由来已久。可是在我们这些天天和软件打交道的人看来，软件工程就像家常便饭，完完全全是一种日常工作和生活方式，真的难以想象没有软件工程的软件开发会是什么样子。
经过一段时期的观察，我逐渐发现了这样一个严酷的现实，想不到现在国内还有这么多人（至少反映在某些号称最最专业的网站、媒体和论坛上）稀里糊涂地怀疑软件工程的重要性和必要性，对“软件工程到底是什么”的理解也是随心所欲、五花八门。我反复思考了导致这一现象背后的方方面面原因。不幸的是，看来很多人在看了《人月神话》之后（或许根本没有细看），就认为布鲁克斯所持的是一种悲观论调，进而从其没有银弹论推导出“软件工程不是银弹”，认为软件工程基本上是无用的神话，宣扬软件工程即一批技术狂人在追求空无缥缈、并不存在的银弹，30 年来软件工程毫无建树……可是我想他们根本错了，完全把《人月神话》的本意搞反了！
又经过一番认真仔细的调查研究，我发现了一个令我惊讶的事实：布氏的 NSB 并没有错，而我们大部分跟着喊“没有银弹”的人很有可能是错的，我们没有真正地理解布教授！
布氏银弹不是万灵药
首先，需要明确银弹不是万灵药的同义词，也就是说我们不能随随便便地在句子当中把“银弹”这个词当作“万灵药”（panacea）来用。
证明：采用反证法。
假设“银弹”等于“万灵药”，那么“OOAD 不是银弹，UML 不是银弹，用例不是银弹，RUP 不是银弹，MDA 不是银弹，软件工程也不是银弹”当然都是对的，因为世上原本就没有万灵药。
可转念一想，“世界上不存在万灵药”这个命题应该是个公理，本来就不需要再次证明，难道布教授前后间隔 9 年时间写了两篇重要的文章，花了这么大的精力，就是为了求证“软件工程当中没有万灵药”？是不是很荒唐？显然这里存在矛盾，故前面的假设不能成立，说明布氏银弹另有含义。
我估计大部分说“没有银弹”的人并没有真正搞懂银弹的含义，也没有领会老布的精神。他们很可能犯了错误：第一种可能是说在废话，第二种可能是在不经意中忽略、排斥了那些真正有价值的技术和方法。举一个误用 NSB（把银弹、万灵药混为一谈）的例子：“多年以来，技术界执着地寻找解决开发过程一切问题的‘银弹’，这些努力无疑是值得尊敬的，不过结果却令人叹息：尽管事实上这种银弹并不存在。60 年代末开始出现的软件工程，曾被当作包治百病的万应良药”。作者显然并没有搞懂什么是银弹，因而这段话也就成为了无聊的废话，为他后续论证“软件工程存在危机”构成了一个假象和错误的前提。
那么，到底银弹为何物？
到底什么是“银弹”？让我们对大名鼎鼎的布氏预言进行一番探究。在有没有银弹这个问题上，如果一定要较真，离开原文到处空喊“没有银弹”恐怕不是科学的做法。我的译文是：
“没有哪一项单一的进展，无论是在工程技术还是管理技术上，能够独立地许诺在一个 10 年内，在软件的生产率、可靠性或简洁性方面，哪怕是取得一个数量级的提高。”
顺便计算一下银弹技术所要求的年平均增长率：
根据定义，有( 1 + x )^10 = 10,
故 x ≈ 0.26
可见布氏银弹实际上要求我们的软件开发生产率每年要保持平均 26% 左右的增长率（或在 10 年内增长 10 倍）。在我们讨论有没有银弹的时候，当然不能离开这个基本判断标准。
布氏银弹之无聊性
其实，追求布氏银弹对于现实的软件开发并没有实际意义。为什么？至少有以下三点理由：
1）对于一个具体的软件产品或工程项目来说，不顾其它一味地提高生产率有什么意义？片面地提高生产率（或可靠性、简洁性）并不是我们真正的目的，企业只有在保证质量、真正满足客户需求并且能获得利润的情况下，追求高生产率和/或高可靠性、高简洁性才是有意义的。所以，如果一项技术或一件工具不是银弹，不能保证 10 倍的改进，我们并不能就因此而轻视、拒绝或抛弃它。
2）为什么偏要规定只能采用单一技术？对一个具体的软件产品或工程项目来说，只要我们的组织还存在缺陷，只要是预计改进效果优于以往，能够保证总体成功、实现质量和业务目标的各种工程技术和管理方法，我们都应该勇敢果断地进行尝试，综合灵活地加以运用，况且究竟如何界定单一技术进展是很困难的。我们往往要求获得综合性的整体增长，追求单一的银弹没有现实价值。
3）为何要求 10 年 10 倍？在评估一项技术的时候，我们通常考虑的是它对今年的项目、产品能否有切实的帮助，世界顶级的软件企业首席科学家一般对于战略性技术也顶多考虑 3-5 年，谈论 10 年 10 倍是没有实际工程意义的。再者，某个工程技术、管理方法虽然有效，但是如果它给项目带来的改善没有达到 26%，比如只有区区的 20%、10%，难道就不好了，就应该抛弃，应该置之不理？
可见老布在下 NSB 这个论断的时候确实采取了一些窍门,期望它至少 10 年内不会失效。然而，NSB 对我们的实际工作又有什么影响和意义呢？至少我们不能想当然地把一件东西“是不是银弹”作为指导我们开展实践，挑选、采用某项技术或工具的标准。
那么，布老先生为什么要提出 NSB？应该不是空穴来风。据我的了解和分析，原因可能是这样的：1986 年的时候，由于作为学术教授的他不满于当时的 CASE 工具开发商所作的过多不实的宣传，于是借 NSB 一说揭示他们的工具存在着很大的局限性——不能解决软件工程的根本问题，同时又为我们指出了一条明路（“There is no royal road, but there is a road.”[1]），他心目中的银弹其实就是指那些未来能够解决根本问题的技术。布氏银弹原本不过是用来嘲讽国外某些 CASE 工具开发商过份宣传的一句玩笑话，结果却被我们国内一群无聊的发烧友没头没脑地拿来攻击软件工程！
揭开真相—有银弹
作为革命性的核心关键技术，各行各业的银弹广泛存在。为了保险起见，老布对软件工程 NSB 只前瞻了 10 年。可是当时没有，不等于将来没有。软件工程的银弹是否真的永远不存在？
布氏银弹所要求的年增长 26% 是否真的很难办到呢？我想，对于国内许多 IT 机构来说，一个项目的效率或质量提高 30% 都不能算是一件很难办到的事，因为我们的工作中还存有大量低效、甚至错误的部分。我不相信无论在管理还是在技术上，我们的软件工程水平都高到了与世界先进发达国家平起平坐的那个程度，连 30% 的再增长空间也没有了。
实际上老布心里是有银弹的，或期盼着银弹的出现，他花了大量篇幅来分析银弹存在的可能性。具体来说，就是重视业务分析、需求分析和软件设计，越接近认识问题、解决问题的本质越好。他告诫 IT 界要区分解决根本问题和次要问题的技术，要更加注重和大力推进前者的研发。我想这才是他的真实本意，可惜国内很多人出于各种原因，莫名其妙地把后半句忘掉了，或者装着没有看到，甚而用 NSB 错误地否定软件工程。
据他分析，当时的一些技术、工具和方法比如高级编程语言、分时技术、统一的编程环境的确不可能是 10 倍率银弹，因为它们解决的仅仅是次要问题，但有一些则是可能的、潜在的、发展中的银弹，他已经给了我们许多提示，比如软件重用、需求精化和快速原型、递增式开发、优秀的设计，并认为其中一些技术相当有希望。如果我们仔细考察一下国外软件工程这 20 年来的发展道路，可以发现银弹或准银弹（追求 100% 的银弹有意义吗？）已经出现或即将出现，甚至已经存在一段时间了。例如，软件重用就是银弹的证据：摩托罗拉公司在编译器项目中通过实现 85% 的重用获得了 10:1 的生产率改进[4]。通用汽车公司的一个库存计划和维护管理系统，由于用 Smalltalk 80 开发替代老的 PL/1 系统，获得的总体生产率改进是 14:1[3]！可见面向对象技术确实是银弹，或至少是银弹的核心配方。
有人认为，因为老布所说的软件工程的“根本问题”从根本上永远无法解决，所以不可能存在银弹，这其实是一种错误的逻辑。“能不能解”和“解的效率”是两码事。布教授所说的“根本问题”，是类似于 NP 完全问题那样的东西吗？当然不是，布教授的 NSB 讲的是解的效率、效能的问题。软件工程不同于理论科研，是实实在在的业务实践和科学应用，软件工程所要解决的问题通常都应该是可解的（由项目的可行性分析保证），否则就不能叫工程了。让我们想想那么多超高难度的软件项目，全球漫游的几亿部手机（中国早已是全球最大的移动通信市场），天上飞的 777、380，让中国人扬眉吐气、让世界吃惊的神舟五号（我们的航天英雄们手中就握有银弹），还有登上火星的勇气号，这些不都是人们运用软件工程、系统工程巧妙地搞定各种极其复杂的“根本问题”而取得的辉煌成就吗？朋友们，实践才是检验真理的唯一标准，不要再拘泥于书本了，用我们智慧的眼光好好看看周围的世界吧。软件工程中到底有没有像硬件技术那样 n*10 倍率的技术和/或管理银弹，用单纯的科学演算和理论推导来证明是相当困难的，恐怕连布教授也无能为力，一切最终只能由事实和数据来说话。
说实话，我们大抵是没有什么资格去和世界软件业的领导者谈论什么银弹的。在 30 多年来已发展成为一个庞大学科的软件工程的方方面面，在民用软件领域，我们有多少原创性的东西，有几样拿的出手，赢得世界学术界和工业界满堂喝彩的成果？至今中国好象还没有自己的对象技术大师吧。而现在看来，跨入 21 世纪，我们仍然需要继续在更广泛的范围内做艰难的软件工程的启蒙工作。所以，千万不要被误人的没有银弹论所蒙蔽！如果我们不管 3721，把凡是自己不熟悉、未掌握的“新”技术、“新”方法都视为假弹、哑弹，把孩子和洗澡水一起抛掉，岂不是冒很大的风险？NSB 在中国泛滥的结果只能使我们更加落后。
重新定义银弹 — 一颗榴弹
以上我们论证了 NSB 的无聊性和布氏银弹的真实存在，而单单提出没有银弹恐怕也不是布教授真实的本意。所以，现在我们有理由、有必要修正银弹的定义，提出自己的银弹说：
1）任何软件工程的核心关键技术都是银弹。谁掌握了软件开发的核心技术，谁就掌握了高效能的银弹。
2）任何一项进展，无论是工程技术还是管理技术，只要能够在软件的生产率、可靠性或简洁性等方面，取得 30% 的提高，那么它就是银弹。
3）任何能够确保软件项目获得成功的主要措施也是银弹，不管它带来的改进率是多少，1% 也行。
4）软件工程的银弹广泛存在，并主要被一些业界领导者所掌握。别人的银弹不一定就是你的银弹，同时，获得银弹也需要付出大量的努力和代价。
5）由于软件工程本质上是一个不断取得各方面因素动态平衡的过程，因而软件工程的银弹必然是一颗榴弹（子母弹），它在质量改进三元论（架构、过程、组织管理）的框架下使用能够发挥最大功效。综合第 3 点，在某种意义上，软件工程本身就是银弹。
所谓的 NSB 只是一篇世界名著的引子，一剂能激发你进行深入思考、认真观察现实的清醒药，而妄图用 NSB 来颠覆软件工程则是非常荒谬的。相反，我们应该着重于把眼前的一个一个项目做好，在让所有项目都 100% 地按时按质成功完成已经是一种奢望的现实情况下，哪怕能够让一个项目的质量或效益提高 10%、5% 也都算是一种成功！要做到这些，别无他法，软件工程才是最重要的保障。
走下神坛的布鲁克斯
《人月神话》是世界软件史上一部非常难得和宝贵的作品，但它并非正规的学术论文集，而只是汇集了布鲁克斯教授关于软件工程早、中期发展的各种深邃思想和精辟观点的杂记，当然不可避免地也会存在一些语义矛盾和逻辑问题。
我们要为时下某些 IT 出版社、所谓的最最专业的媒体的市场策划以及各种形形色色的枪手、托儿们进一言：天底下哪来那么多的圣经和必读经典？据我所知，自创世纪以来世界上圣经好象只有两个正式的发布版本：《新约》和《旧约》。当然，一些西方人为技术书籍起名喜欢用 bible 这个词，但我们是否应该照搬，一起来炒“圣经”呢？按我的理解，圣经必然是要我们每个礼拜捧起来虔诚地诵读的。软件界存在圣人，存在圣经吗？我们最好不要人为地制造新的神话，以免将来被人取笑。
离老布首次提出 NSB 竟然已经过去 17 年了！有意思的是，UP（统一过程）、Use Case（用例）、UML（统一建模语言）、OOAD（面向对象分析设计）、MDA（模型驱动架构）、CBD（基于构件的软件开发）、设计模式、架构、框架、分析模式、重用、领域工程、业务工程……等等等等，几乎 17 年来软件工程所有主要的努力、取得的重大进步都是朝着解决布老提出的“根本问题”这个方向去的。想到这里，令人不禁油生敬佩之情,惊讶于他老人家的眼光。可惜，业界似乎很少有人看到这点，只有一片到处浮躁、浅薄甚至错误的没有银弹的声音。布老有先见之明，并用他自己独特的方式为业界指明了方向，大家已经而且正在朝着这条道路前进，这就是他的伟大之处，NSB 的真正意义和价值也正在于此。
我们确实应该听从老布的真言，更加认真和热情地关注业务建模、领域工程、软件的需求分析和架构设计、软件重用与构件工程、软件项目管理等等当代国际先进的软件工程管理和技术领域，这些都是能给我们的现在和未来带来实际效益的、潜在的银弹！
我的建议
我发现，软件史上至少有两个著名的软件工程经典论断（一个是软件开发的瀑布模型，另一个就是没有银弹论），在不经意之中从侧面帮了美国人大忙，帮助他们在软件工业上确立并保持了长期的世界领导地位。真正聪明的美国软件人，根据自己内心真实的判断，并没有听命于这些所谓的经典判断,因而他们虽经历了种种坷坷绊绊，却仍然取得了举世瞩目的骄人成绩。
我们当然不能怪罗伊斯和布老先生，人家是出于好心肠，是就事论事，并没有说错，只能怪我们自己，谁叫我们没有认认真真地当好小学生，没有学会独立思考、真正领会精神，凡是外国著名专家、著名大师、著名机构提供的经验、开的方子一概都乐意照单全收呢？
如果你通过仔细的评估，预计到有什么开发技术或管理方法能使你的项目或产品获得短期和/或长期的成功，那么就勇敢地去尝试，理性地去分析和总结，即使偶尔失败也不要气馁。这些事情并不难做到，因为你肯定不是世界上第一个这么做的人，所以千万不要再没头没脑地说这个不存在，那个没用。请务必留意掠过身边的银弹、铜弹或铁弹，抓住每一次改进的机会，奇迹就在脚下!
参考文献[1] Brooks F. P., Jr. 著，《人月神话》（影印版），中国电力出版社，2003年3月第1版。
[2] Brooks F. P., Jr. 著，汪颖译，《人月神话》，清华大学出版社，2002年11月第1版。
[3] Graham I. 著，袁兆山等译，《面向对象方法原理与实践》，机械工业出版社，2003年3月第1版。
[4] Jacobson I., et al, Software Reuse: Architecture, Process and Organization for Business Success（《软件重用》影印版）, 世界图书出版公司北京公司，1998年3月第1版。
后记
其实这篇文章已经酝酿一年多了。在前半部分，我已经论证了布氏银弹的无效性，在后续的版本中，我将打扫预留的伏笔，并正式提出“张氏银弹说“，其它内容还将包括：什么是A型银弹和B型银弹？软件工程的根本问题不可解吗？Cox, Harel, Brooks，孰对孰错，以及对老布原文的逐段解析等等。如果全部完成，预计将达到5-6万字。不过，当前版本基本的意思已经具备了，并且取得了很好的效果。感谢网友们的热情支持与鼓励！
最新发现的银弹：通用汽车公司（GM）的一个早期应用——用于汽车修理维护部件的库存计划和维护管理系统。旧的系统由265,000行PL/1代码组成，花了12.5人年，运行时需要13.6M内存，替代系统用Smalltalk 80开发，总共用了不到1人年的时间，系统只有22,000行代码，内存仅需1.1M。两个系统的性能大致相同，但二者的总体生产率之比是14:1！ p45, Ian Graham著，袁兆山等译，《面向对象方法原理与实践》（原书Object-Oriented Methods: Principles & Practice, 2001年Pearson第3版）机械工业出版社 2003年3月第1版。 经初步判断，这一事实应该发生在1980-1995年期间。