《沒有銀彈：軟件工程的本質性與附屬性工作》（英語：No Silver Bullet—Essence and Accidents of Software Engineering）是IBM大型電腦之父佛瑞德·布魯克斯所發表一篇關於軟件工程的論文，原先是在1986年都柏林IFIP研討會的一篇受邀論文[1][2]，隔年電機電子工程師學會《Computer》也轉載了這篇文章，他們用了幾張《倫敦狼人》之類的電影劇照來當作說明[3]，還加上了一段〈終結狼人〉的附註，用來引出非銀彈則不能成功的（現代）傳說。該論述中強調由於軟件的複雜性本質，而使真正的銀彈[註 1]並不存在；所謂的沒有銀彈是指沒有任何一項技術或方法可使軟件工程的生產力在十年內提高十倍。
 | 此條目需要補充更多來源。 (2012年7月9日) |
摘要
所有軟件創作都包括了本質性工作（essential task）和附屬性工作（accidental task）。前者是去創造出一種由抽象的軟件實體所組成的複雜概念結構，後者則是用程式語言來表現這些抽象的實體，並在某些空間和速度的限制之下，將程式對應至機器語言。[註 2]
現在，若跟本質性的工作相比，軟件工程人員所做的事，還有多少算是花在附屬性的工作上呢？除非附屬性工作要耗費的心力超過全部工作的9/10，否則就算是將所有的附屬性工作降至零，也無法將整個開發工作的輕鬆程度提升一個數量級。以往，軟件生產力的重要進展絕大部分是來自於人為障礙的排除，像是嚴苛的硬件限制、難用的程式語言、上機時間（machine time）的不足等等，這些都是造成附屬性工作益發困難的原因。
問題之所在－銀彈與軟件專案
在民俗傳說裏，所有能讓我們充滿夢靨的怪物之中，沒有比狼人更可怕的了，因為牠們會突然地從一般人變身為恐怖的怪獸，因此人們嘗試着尋找能夠奇蹟似地將狼人一槍斃命的銀彈。
我們熟悉的軟件專案也有類似的特質（以一個不懂技術的管理者角度來看），平常看似單純而率直，但很可能一轉眼就變成一隻時程延誤、預算超支、產品充滿瑕疵的怪獸，所以，我們聽到了絕望的呼喚，渴望有一種銀彈，能夠有效降低軟件開發的成本，就跟電腦硬件成本能快速下降一樣。
但是，我們預見，從現在開始的十年之內，將不會看到任何銀彈，無論是在技術上或管理上，都不會有任何單一的重大突破，能夠保證在生產力、可靠度或簡潔性上獲得改善，甚至，連一個數量級的改善都不會有。
然而，懷疑並非悲觀，雖然我們預見不會有任何重大的突破，而且事實上，我相信發生這種重大突破也不符軟件的本質，但是，仍然有許多令人振奮的創新正在進行當中，若能按部就班、持之以恆地予以發展、散佈，並靈活運用的話，想必應該會得到一個數量級的進展。捷徑是不會有的，但有志者事竟成。
人類能克服疾病的第一步，就是以細菌說（germ theory）[註 4]淘汰了惡魔說（demon theory）[註 5]和體液說（humours theory）[註 6]，正是這一步，帶給了人類希望，粉碎了所有奇蹟式的冀望，告訴人們進步是要靠按部就班、不辭勞苦而來，得在清潔衛生方面持續不斷地投入心血，養成良好習慣，才是正道。如今，我們面對軟件工程也是一樣。
《沒有銀彈》主張並斷言在未來的十年之內（從1986年文章發表後開始計算），不會有任何單一的軟件工程上的突破，能夠讓程式設計的生產力得到一個數量級的提升。不過，作者認為這個假設現在已不再成立。
假設軟件開發的總工作量為10，其中，本質性工作佔掉1，附屬性工作佔掉9，那麼改善附屬性工作，將之消除，就可以把軟件工作量減輕到1（因為附屬性工作變成0），此時我們可以說，軟件工作開發的輕鬆程度提升了一個數量級（因為由10進步到1，差10倍）。
軟件開發的困難
布魯克斯將軟件開發的困難分為兩類，這篇經典論文的核心論述通常被解釋為複雜的軟件工程問題無法靠簡單的答案來解決。布魯克斯相信軟件開發真正的困難，是在於這種概念構造的規格制定、設計和測試，而並非在孜孜矻矻於它的呈現方式，以及測試該呈現方式的精確程度。
- 本質性（essence）：軟件本身在概念（conceptual）建構上存先天的困難；亦即如何從抽象性問題，發展出具體概念上的解決方案。
- 附屬性（accident）：將概念上的構思施行於電腦上，所遭遇到的困難。
布魯克斯提到，有某些地方已經被附屬性（accident）和附屬的（accidental）這些字眼給混淆了，這個字眼是出自於亞里士多德的古老用法[註 7]。就英語：accidental的這個字眼而言，他所指的並不是偶然發生的意思，也不是意外不幸的意思，而是比較接近伴隨的或次要的意思。
布魯克斯認為，附加性的困難會隨着工具的改善而逐漸淡化，反而是本質性的困難最難以解決，因為大部分的活動是發生在人們的腦海裏，缺乏有效的輔助工具。依照布魯克斯的說法有下列幾項：[6]
高階語言達成了什麼樣的使命呢？它使程式不再陷入許多原來附屬在程式裏的複雜性。一支抽象的程式所包含的是一些概念的構造：函數、資料型別、先後順序的關係，以及訊息傳遞的方式，然而實際上，與機械碼攸關的其實是位元、暫存器、條件、分支、通道、磁碟等等。高階語言可以將抽象程式裏所必要的構造予以具體化，並且避免掉所有更低階的東西，在這種情形下，它把跟程式內涵一點關係都沒有的那一整層複雜性給去除了。
分時（time-sharing）技術所挑戰的是另一個截然不同的難題，因為分時，確保了即時性，使我們得以持續保住腦子裏對複雜的概觀。分時技術所能貢獻的底限也可以直接推算出來，由於其主要的效用就是縮短系統的反應時間，當這項時間趨近於零，並在某一點上跨越了人類所能夠察覺到有系統反應時間存在的臨界點，大約是十分之一秒，低於這個值，就不會再有任何效益了。
Unix和Interlisp是第一個得到廣泛使用的整合軟件開發環境，並且也被公認已將生產力提升了好幾倍。這方面所挑戰的附屬性難題，就是藉由完整的程式庫、統一的檔案格式、管道（pipe）和過濾器（filter），以促成軟件的共用，於是，任何概念的構造在理論上都可以呼叫、傳遞和運用在另一個對象，而實務上，這點也很容易就可以辦得到。這方面的突破隨後也帶動了整個工具軟件的發展，因為每一個新工具只要用的是標準規格，就可以適用於任何程式。
尋找銀彈
- Ada和其他高階語言的進展
程式語言Ada是1980年代的一個通用型高階語言。事實上，Ada不只是反映了在語言概念上的演進，同時也具體實現了一些助長現代設計與模組化概念的特徵；也許，Ada的理念才是比Ada語言本身更先進的地方，這理念就是：模組化（modularity）、抽象資料型別（abstract data type）、階層式結構（hierarchical structure）。
相對於當今流行的各種技術，物件導向程式設計（object-oriented programming）已被許多軟件工程的學生寄予了更多的希望[8]，達特茅斯學院的Mark Sherman指出，有兩個不同的概念我們必須小心地加以分辨，從名稱上就可以看出這兩個概念的不同：抽象資料型別和階層式型別。後者也被稱為類別（class）。所謂抽象資料型別，其概念就是一個物件的型別應該由一個名稱、一組適當的值和一組適當的操作方式來定義，而不是以它儲存的結構來定義，這部分應該是要被隱藏起來的，例如Ada的包裹（package，使用私有型別）或Modula的模組（module）。
評價迴響
雖然《人月神話》引發了許多論述，但爭議很少，倒是《沒有銀彈》引發了不少持相反意見的文章，包括寄給期刊主編的一些信件，以及到今天都還在持續出現的一些書函和短評，這其中有大部分是對『不會有任何特效藥的主張』提出反駁。[註 8]
1990年，Brad Cox[註 9]發表一篇《銀彈存在》（"There Is a Silver Bullet"）[9][10]，指出採取可再利用（reusable）、可替換組件的方式來對付屬於概念本質性部分的問題。Glass、Vessey和Conger在他們1992年的一篇論文中就指出，有充分的證據顯示，對銀彈這種沒有意義的研究仍尚未停止[11]。
David Harel在1992年的一篇文獻《緊咬銀彈》（"Biting the Silver Bullet" ）[12]中，對已經發表的《沒有銀彈》進行非常仔細的分析[13]。Harel認為《沒有銀彈》和1984年Parnas《戰略防禦系統軟件面面觀》[14]這兩篇都寫得太過於絕望了，於是他針對這一點來闡述較為光明的一面，他的文章還用了個副標題是「讓系統開發走向一個光明的未來」。
就Harel的認知，他認為造成《沒有銀彈》悲觀的原因有三點：
- 本質性和附屬性的二分法。
- 對每一個可能的銀彈採取個別單獨評論的方式。
- 只預測10年，這對「預期任何重大的突破」而言，並沒有足夠長的時間。
Harel更提出了一項假想實驗，他假定《沒有銀彈》的主張不變，只是發表的時間換做是在1952年，而非1986年。他這時用的是歸謬法（reducto ad absurdum）[註 10]，用來反駁自附屬性中切分出本質性的作法。
Caper Jones曾提出一個敏銳的見解，這個見解最初是寫在一連串非正式的紀錄中，後來出現在書上，幾個與布魯克斯通訊的朋友也提到過。《沒有銀彈》就如同大部分的論文一般，都把焦點集中在生產力，也就是軟件每單位的輸入成本能得到多少輸出效果。Jones則表示：「把重點放在質素上，生產力將隨之而來」[15][16]。他認為，只要是成本過高和時程落後的專案，都耗費了非常多的額外時間和工作在尋找並修正規格、設計、實作中的錯誤。Jones並提出資料佐證，缺乏有系統的質素控制與發生時程落後的災難，這兩者之間有強烈的相關性。
Caper Jones相信，兩份同等的Cobol程式分別花10年編寫，但其中一份使用結構化的方法，另一份則否，那麼所得到的效果將相差3倍。
註釋
參考文獻
外部連結
參見
.gif){kind=small}
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
