（壹年前我寫作此文，實在是因為看不慣對於軟件技術進步、軟件技術革新，國內多少年來總有壹些人老是熱衷於喊世界上“沒有銀彈”，全以為自己對軟件科技看穿了、看透了（他們真讀懂了《人月神話》？），便喜歡對別人的埋頭苦幹冷嘲熱諷。在這些人眼裏，“沒有銀彈”和“軟件工程無用論”是聯系在壹起的。既然沒有銀彈，軟件工程對於所謂的“根本問題”無能為力，那麽我們與美歐軟件的差距也就沒有什麽了不起的，於是乎可以心安理得繼續安穩地過阿 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年期間。