推薦理由
作者Frederick P. Brooks,是北卡羅萊納大學Kenan-Flagler商學院的計算機科學教授。他曾榮獲圖靈獎，美國計算機協會（ACM）稱贊他“對計算機體系結構、操作系統和軟件工程做出了里程碑式的貢獻。”
作為軟件工程領域的重要著作，《人月神話》結合工業界具體的大型系統開發實例，對軟件開發領域的諸多問題提出了思考和見解，許多論斷被軟件開發從業者奉為圭臬。經過數十年的時間淬煉，對今天的大型軟件開發都有啟發意義。
本書要點
- 焦油坑：大型系統開發中各種問題纏繞和積累在一起，使得大型系統的開發十分困難。
- 人月神話：在軟件開發領域，用人月作為工作規模的衡量指標并不適用。
- 外科手術式隊伍：軟件開發團隊可以參照外科手術式隊伍組成、運作、擴建
- 貴族專治、民主政治和系統設計：在系統設計中，概念完整性應該是最重要考慮的因素
- 畫蛇添足：架構師和項目經理都需要避免second-system effect
- 貫徹執行：定義良好的規格說明是重要的，會議、測試小組等形式是保證設計執行的良好方式。
- 為什么巴比倫塔會失敗？：軟件團隊的交流和組織是軟件開發成敗的關鍵
- 胸有成竹：對大型軟件系統產品的開發所需的時間和資源進行準確的估測，能讓我們在項目進度和前景胸有成竹
- 削足適履：最大化資源利用率；巧妙的數據結構
- 提綱挈領：文檔是重要和必要的
- 未雨綢繆：只有“變化“是不變的，為需求和設計的變化做準備
- 干將莫邪：項目經理需要為軟件開發團隊配備完備的工具
- 整體部分：好的自頂向下的設計避免缺陷
- 禍起蕭墻：軟件開發團隊需要為計劃和控制投入資源
- 另外一面：提供給用戶的使用說明等文檔是軟件呈現給用戶的另外一面
- 《沒有銀彈》：由于軟件的復雜性，一致性，變化性和不可見性，解決軟件危機的銀彈并不存在
- 再論《沒有銀彈》：人們期待中的重大突破不可能在近期內到來
精編書摘
焦油坑
過去幾十年的大型系統開發猶如焦油坑，各種團隊一個接一個淹沒在焦油坑中。表面上沒有任何一個單獨的問題導致困難，當他們相互纏繞和累積在一起的時候，團隊的行動就會變得越來越慢。如果想看清這個問題的本質，就必須試圖先去理解它。
編程系統產品是大多數系統開發的目標，然而它的成本是程序的9倍。
編程的樂趣在于：編程是一種創建事物的純粹快樂；快樂來自于開發對其他人有用的東西；整個過程體現出魔術般的力量；學習的樂趣；工作在如此易于駕馭的介質上。
編程的苦惱在于：必須追求完美；由他人來設定目標，供給資源，提供信息；概念性設計是有趣的，但尋找瑣碎的bug卻只是一項重復性的活動；調試和查錯是往往是線性收斂的；產品在完成時可能就已經過時。
人月神話
軟件項目中缺乏合理的時間進度的主要原因是：
? 對估算技術缺乏有效的研究
? 采用的估算技術隱含的假設人和月可以互換，錯誤的將工作量與進度相互混淆
? 軟件經理由于對自己的估算缺乏信心，往往不會有耐心持續的進行估算這項工作
? 對進度缺少跟蹤和監督
? 當意識到進度的偏移時，下意識的反應是增加人力
編程人員的樂觀主義并不應該是理所應當的
用人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話，在軟件開發項目中，由于任務在次序上的不可分解、培訓和交流的需要，人月并不適用。
在早期進度策劃時，允許充分的系統測試時間是非常重要的。
Brooks法則：
向進度落后的項目中增加人手，只會使進度更加落后。
外科手術式隊伍
外科手術式隊伍的組成：外科醫生（首席程序員）、副手、管理員、編輯、兩個秘書、程序職員、工具維護人員、測試人員、語言專家。
外科手術式隊伍的運作：
? 首席程序員和副手都了解所有的設計和全部的代碼，節省了空間分配、磁盤訪問等的勞動量，同時也確保了工作概念上的完整性。
? 不存在利益上的差別，觀點不一致由首席程序員單方面來統一。
? 剩余人員職能的專業化分工是高效的關鍵，使成員之間采用非常簡單的交流模式成為可能。
外科手術式隊伍的擴建成功依賴于這樣一個事實：每個部分的概念完整性得到了徹底的提高。
貴族專治、民主政治和系統設計
在系統設計中，概念完整性應該是最重要考慮的因素
概念完整性的獲得：
? 每個部分必須反映相同的原理、原則和一致的折衷機制。在語法上，每個部分應使用相同的技巧；在語義上，應具有相同的相似性。
? 對于非常大型的項目，將設計方法、體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法。
外部的體系結構規定實際上是增強， 而不是限制實現小組的創造性。
整個創造性活動包括了三個獨立的階段： 體系結構（ architecture）、 設計實現（ implementation）、 物理實現（ realization）。 在實際情況中，它們往往可以同時開始和并發地進行。
同工作的水平分割相比， 垂直劃分從根本上大大減少了勞動量， 結果是使交流徹底地簡化，概念完整性得到大幅提高。
畫蛇添足
架構師的交互準則和機制：
? 牢記是開發人員承擔創造性和發明性的實現責任，所以架構師只能建議而不能支配
? 時刻準備著為所指定的說明建議一種實現的方法，同樣準備接受其他任何能達到目標的方法。
? 對上述的建議保持低調和平靜
? 準備放棄堅持所作的改進和建議
架構師如何避免畫蛇添足--開發第二個系統所引起的后果（second-system effect）?
? 有意識關注那些系統的特殊危險， 運用特別的自我約束準則， 來避免那些功能上的修飾
? 根據系統基本理念及目的變更， 舍棄一些功能
項目經理如何避免畫蛇添足（second-system effect）?
他必須堅持至少擁有兩個系統以上開發經驗結構師的決定。 同時， 保持對特殊誘惑的警覺， 他可以不斷提出正確的問題，確保原則上的概念和目標在詳細設計中得到完整的體現。
貫徹執行
手冊、或者書面規格說明，是一個非常必要的工具，盡管光有文檔是不夠的。
會議是必要的，我們把會議分成兩個級別： 周例會和年度大會——這實際上是一種非常有效的方式
設立測試小組是使設計決策得以貫徹執行的必要手段， 同樣也是需要盡早著手，與設計同時實施的重要環節
為什么巴比倫塔會失敗？
團隊相互之間的交流溝通的可能的途徑有：
非正式途徑；會議；工作手冊
編程人員僅了解自己負責的部分，而不是整個系統的開發細節時，工作效率最高。 這種方法的先決條件是精確和完整地定義所有接口。這的確是一個徹底的解決方法。如果能處理得好，的確是能解決很多“災難“。一個好的信息系統不但能暴露接口錯誤，還能有助于改正錯誤
交流和交流的結果——組織， 是成功的關鍵。 交流和組織的技能需要管理者仔細考慮， 相關經驗的積累和能力的提高同軟件技術本身一樣重要
胸有成竹
對大型軟件系統產品的開發所需的時間和資源進行準確的估測，能讓我們在項目進度和前景胸有成竹。軟件代碼的開發效率和代碼模塊之間所需的交互相關。界面交互復雜的程序需要更多的測試和調試時間，單純地增加人手并不能有助于開發效率的提高。
削足適履
同任何開銷一樣， 規模本身不是壞事，但不必要的規模是不可取的
創造出自精湛的技藝，精煉、充分和快速的程序也是如此。技藝改進的結果往往是戰略上的突破， 而不僅僅是技巧上的提高
更普遍的是，戰略上突破常來自數據或表的重新表達——這是程序的核心所在
提綱挈領
軟件項目的關鍵文檔：目標；產品技術說明；進度表；預算；工作空間分配；組織圖
正式文檔的必要性：書面記錄決策是必要的；文檔能夠作為同其他人的溝通渠道；項目經理的文檔可以作為數據基礎和檢查列表
未雨綢繆
目標上的一些變化無可避免，事先為它們做準備總比假設它們不會出現要好得多。 不但目標上的變化不可避免， 而且設計策略和技術上的變化也不可避免。 拋棄原型概念本身就是對事實的接受——隨著學習的過程更改設計
系統軟件開發是減少混亂度（減少熵）的過程，所以它本身是處于亞穩態的。軟件維護是提高混亂度（增加熵） 的過程， 即使是最熟練的軟件維護工作， 也只是放緩了系統退化到非穩態的進程
干將莫邪（sharp tools）
項目經理必須考慮、計劃、組織的工具有：
? 計算機設施，需要硬件和使用安排策略
? 操作系統，提供服務的方式必須明了
? 語言，語言的使用方針必須明確
? 實用程序、調試輔助程序、測試用例生成工具和處理文檔的字處理系統
整體部分
許許多多的失敗完全源于那些產品未精確定義的地方。
好的自頂向下設計從四個方面避免了 bug。
? 首先， 清晰的結構和表達方式更容易對需求和模塊功能進行精確的描述；
? 其次， 模塊分割和模塊獨立性避免了系統級的 bug。
? 另外， 細節的隱藏使結構上的缺陷更加容易識別。
? 第四，設計在每個精化步驟的層次上是可以測試的，所以測試可以盡早開始，并且每個步驟的重點可以放在合適的級別上。
禍起蕭墻
好的里程碑對團隊來說實際上是一項服務，可以用來向項目經理提出合理要求的一項服務， 而不確切的里程碑是難以處理的負擔。
對計劃和控制職能進行適度的技術人力投資是非常值得贊賞的。它對項目的貢獻方式和直接開發軟件產品有很大的不同
另外一面
對于軟件編程產品來說， 程序向用戶所呈現的面貌與提供給機器識別的內容同樣重要
程序修改人員所使用的文檔中， 除了描述事情如何以外， 還應闡述它為什么那樣。對于加深理解，目的是非常關鍵的，但即使是高級語言的語法，也不能表達目的
沒有銀彈
所有軟件活動包括根本任務——打造由抽象軟件實體構成的復雜概念結構，次要任務——使用編程語言表達這些抽象實體， 在空間和時間限制內將它們映射成機器語言。
軟件開發中困難的部分是規格化、設計和測試這些概念上的結構，而不是對概念進行表達和對實現逼真程度進行驗證
現代軟件系統中復雜度、一致性、可變性和不可見性是無法規避的。
銀彈的希望：Ada和其他高級編程語言；面向對象編程；人工智能；專家系統；“自動”編程；圖形化編程；程序驗證；環境和工具；工作站。
針對概念上根本問題的頗具前途的方法：
購買和自行開發；需求精煉和快速原型；增量開發--增長，而非搭建系統；卓越的設計人員
再論《沒有銀彈》
《 沒有銀彈》 提出了全力解決復雜性問題的方法， 這種方法可以在現實中取得十分樂觀的進展。 它倡導向軟件系統增加必要的復雜性：層次化，通過分層的模塊或者對象；增量化，從而系統可以持續地運行
