《沒有銀彈：軟體工程的本質性與附屬性工作》（）是IBM大型電腦之父佛瑞德·布魯克斯發表的一篇軟體工程論文。這篇文章最早是他在1986年都柏林IFIP研討會的受邀論文。隔年，電機電子工程師學會《Computer》也轉載了這篇文章，並配上《》等電影劇照作為說明，同時加入〈終結狼人〉的附註，帶出「只有銀彈才能解決問題」的現代寓意。文章強調，軟體的複雜性是本質性的，因此真正的銀彈並不存在；所謂「沒有銀彈」，指的是沒有任何單一技術或方法，能在十年內讓軟體工程生產力提升十倍。
摘要
所有軟體開發都包含本質性工作（essential task）和附屬性工作（accidental task）。前者是建立由抽象軟體實體構成的複雜概念結構，後者則是用程式語言把這些抽象實體實作出來，並在空間與速度限制下，將程式對應到機器語言。
如果附屬性工作占比不到全部工作的9/10，那麼即使把附屬性工作完全消除，也無法讓整體開發效率提升一個數量級。過去軟體生產力的大幅進步，多半來自移除人為障礙，例如嚴苛的硬體限制、難用的程式語言，以及上機時間（machine time）不足等，這些因素都會讓附屬性工作變得更困難。
問題之所在－銀彈與軟體專案
佛瑞德·布魯克斯在《沒有銀彈》中寫道：
《沒有銀彈》主張，在未來十年內（自1986年發表起算），不會有任何單一軟體工程突破，能讓程式設計生產力提升一個數量級。不過，作者後來認為這個假設已不再成立。
假設軟體開發總工作量為10，其中本質性工作占1、附屬性工作占9。若能完全消除附屬性工作，總工作量就會降到1，此時可視為開發效率提升一個數量級（由10降到1，即10倍差距）。
軟體開發的困難
布魯克斯把軟體開發的困難分成兩類。這篇論文的核心觀點是：複雜的軟體工程問題無法用單一簡單方法解決。他認為軟體開發真正的難點在概念架構的規格制定、設計與測試，而不是表達方式本身，或對表達方式的精確檢驗。
- 本質性（essence）：軟體在概念（conceptual）建構上的先天困難，也就是如何從抽象問題發展出具體解法。
- 附屬性（accident）：把概念構想實作到電腦上時遇到的困難。
布魯克斯指出，附屬性（accident）和附屬的（accidental）常被混用。這個詞源自亞里斯多德的古老用法。在這裡，不是指「偶然發生」或「意外不幸」，而是更接近「伴隨的」或「次要的」。
造成本質性困難的原因
布魯克斯認為，附屬性困難會隨著工具改進而逐步減少，但本質性困難最難解決，因為大部分工作都在人的思考過程中進行，能直接幫上忙的工具有限。他列出以下幾項：
- 複雜性（complexity）：軟體要處理的問題通常牽涉到計算步驟，這是一種人為的、抽象的智能活動，本身就很複雜。
- 隱匿性（invisibility）：還沒做完的軟體看不見，就算用圖示來說明，也常常沒辦法把結構講清楚，造成溝通上的困難。
- 配合性（conformity）：在大型軟體裡，各個子系統的介面必須互相配合。但隨著時間和環境變化，要一直保持一致並不容易。
- 易變性（changeability）：軟體運作的環境包含人、法規、硬體、應用領域等等，這些因素都會不斷變化。
過去的突破解決了附屬性的困難
高階語言
高階語言的主要作用，是讓程式不必被大量底層細節綁住。抽象程式關心的是函式、資料型別、執行順序、訊息傳遞等概念；但機器碼實際處理的是位元、暫存器、條件、分支、通道、磁碟等底層元素。高階語言把程式需要的概念具體化，同時隔離底層細節，等於移除了與程式本質無關的一層複雜性。
分時技術
分時（time-sharing）技術解決的是即時回應問題。有了分時，系統互動更連續，開發者在思考時較能維持對整體脈絡的掌握。分時技術的效益也有上限：它主要改善系統反應時間，當反應時間短到人類幾乎無感（約十分之一秒）後，再加速的實際差異就不大。
統一的開發環境
Unix和Interlisp是最早被廣泛使用的整合軟體開發環境，普遍被認為讓生產力提升數倍。它們處理附屬性難題的方式，是透過完整程式庫、統一檔案格式、管道（pipe）和（filter）等機制提升軟體可共用性。概念上的構造因此更容易被呼叫、傳遞或套用到其他場景。這項突破後來也推動了工具軟體發展，因為新工具只要遵守標準規格，就能用在多種程式上。
尋找銀彈
; Ada和其他高階語言的進展
程式語言Ada是1980年代的通用型高階語言。Ada不僅反映了語言概念的演進，也實作了多項支持現代設計與模組化的特徵。相較於語言本身，Ada更被重視的是其設計理念：模組化（modularity）、抽象資料型別（abstract data type）、階層式結構（hierarchical structure）。
; 物件導向程式設計
相較於當時其他流行技術，物件導向程式設計（object-oriented programming）被許多軟體工程研究者寄予更高期待，达特茅斯学院的Mark Sherman指出，有兩個不同的概念我們必須小心地加以分辨，從名稱上就可以看出這兩個概念的不同：抽象資料型別和階層式型別。後者也被稱為類別（class）。所謂抽象資料型別，其概念就是一個物件的型別應該由一個名稱、一組適當的值和一組適當的操作方式來定義，而不是以它儲存的結構來定義，這部分應該是要被隱藏起來的，例如Ada的包裹（package，使用私有型別）或Modula的模組（module）。
*人工智慧
*專家系統
*自動化程式設計
*視覺化或圖形化程式設計
*軟體的驗證
*環境與工具
*工作站
評價迴響
雖然《人月神話》引發許多討論，但爭議相對較少；《沒有銀彈》則引來更多反對意見，包括寄給期刊主編的信件，以及後續持續出現的書函與短評，其中相當一部分都在反駁「不會有任何特效藥」的主張。
1990年，Brad Cox發表〈銀彈存在〉（"There Is a Silver Bullet"），主張可用可再利用（reusable）、可替換組件的方法來處理概念本質性的問題。Glass、Vessey和Conger在1992年的論文中指出，有充分證據顯示，關於銀彈這類議題的研究仍未停止。
Harel的分析
David Harel在1992年的一篇文獻《緊咬銀彈》（"Biting the Silver Bullet"
）中，對《沒有銀彈》做了細緻分析。Harel認為《沒有銀彈》和1984年Parnas《戰略防禦系統軟體面面觀》都寫得過於悲觀，因此嘗試補充較正向的一面，並在副標題中提出「讓系統開發走向一個光明的未來」。
就Harel的認知，他認為造成《沒有銀彈》悲觀的原因有三點：
- 本質性和附屬性的二分法。
- 對每一個可能的銀彈採取個別單獨評論的方式。
- 只預測10年，這對「預期任何重大的突破」而言，並沒有足夠長的時間。
Harel還提出一項假想實驗：假設《沒有銀彈》的主張不變，但發表時間改為1952年而非1986年。他使用歸謬法（reducto ad absurdum），反駁從附屬性中硬性切分出本質性的做法。
Jones的觀點
Caper Jones曾提出一個重要觀點，最早出現在一系列非正式紀錄中，後來收錄於書中，也被數位與布魯克斯通信的人提及。《沒有銀彈》和多數論文一樣，把焦點放在生產力，也就是每單位軟體輸入成本能產生多少輸出。Jones則主張：「把重點放在品質上，生產力會隨之而來」。他認為，凡是成本過高、時程落後的專案，都會把大量額外時間花在找出並修正規格、設計與實作錯誤上。Jones也提出資料顯示，缺乏系統化品質控制，與時程延誤災難之間有強烈相關性。
Caper Jones認為，若兩份同等的Cobol程式都花10年編寫，但其中一份採用結構化方法、另一份沒有，最終效果可相差3倍。
注释
參考文獻
引用
来源
; 期刊文章
*
*
; 书籍
*
外部連結
- [https://web.archive.org/web/20150816084239/http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html No Silver Bullet: Essence and Accidents of Software Engineering], by Frederick P. Brooks, Jr.
- [https://web.archive.org/web/20160121022416/http://barrapunto.com/~pacoescriba/journal/29784 No hay balas de plata: Lo esencial y lo accidental en la Ingeniería del Software], by Frederick P. Brooks, Jr.
- [http://www.uml.org.cn/oobject/200509141.htm 论银弹的存在]
參見
- 佛瑞德·布魯克斯
- 《人月神話》
- 軟體危機
- 银色子弹 → 狼人
评论 (0)