第1章    焦油坑    /    001

編程繫統產品 / 003

職業的樂趣 /  005

職業的苦惱 /  006

第2章    人月神話    /    009

樂觀主義 / 011

人 月 / 013

繫統測試 / 016

怯懦的估算 / 018

重復產生的進度災難 / 019

第3章    外科手術團隊    /    025

問 題 / 027

Mills的建議 / 029

如何運作 / 032

團隊的擴建 / 033

第4章    貴族制、民主制和繫統設計    /    035

概念上的完整性 / 037

獲得概念的完整性 / 038

貴族制和民主制 / 039

在等待時，實現人員做什麼 / 042

第5章    第二繫統效應     /    045

架構師的互動紀律 / 047

自律—第二繫統效應 / 048

第6章    傳遞消息    /    053

書面規約—手冊 / 055

形式化定義 / 056

直接整合 / 059

會議和大會 / 059

第7章    為什麼巴別塔會失敗     /    065

巴別塔的管理教訓 / 067

大型編程項目中的交流 / 068

項目工作手冊 / 068

大型編程項目的組織架構 / 072

第8章    胸有成竹    /    077

Portman的數據 / 080

Aron的數據 / 081

Harr的數據 / 082

OS/360的數據 /  083

Corbató的數據 /  084

第9章    削足適履    /    085

作為成本的程序空間 / 087

規模控制 /  088

空間技能 /  090

數據的表現形式是編程的根本 / 091

第10章     提綱挈領    /    093

計算機產品的文檔 / 095

大學科繫的文檔 /  097

軟件項目的文檔 /  097

為什麼要有正式的文檔 /  098

第11章     未雨綢繆    /    101

試驗性工廠和增大規模 /  103

唯一不變的就是變化本身 / 104

為變更設計繫統 / 104

為變更計劃組織架構 /  105

前進兩步，後退一步 /  107

前進一步，後退一步 / 109

第12章     干將莫邪    /    111

目標機器 / 114

輔助機器和數據服務 / 116

高級語言和交互式編程 /  119

第13章     整體部分    /    123

剔除bug的設計 / 125

調試 /  127

繫統集成調試 /  130

第14章     禍起蕭牆    /    135

是裡程碑還是沉重的負擔 / 137

“其他的部分反正會落後” / 139

地毯的下面 / 140

第15章     另外一面    /    145

需要什麼文檔 / 148

流程圖 / 150

自文檔化的程序 / 154

第16章     沒有銀彈—— 軟件工程中的根本和次要問題   /    161

摘 要 / 163

介 紹 / 163

根本困難 / 164

以往解決次要困難的一些突破 / 169

銀彈的希望 / 170

針對概念上根本問題的頗具前途的方法 / 179

第17章     再論“沒有銀彈”     /    187

人狼和其他恐怖傳說 / 189

存在著銀彈—就在這裡 / 189

含糊的表達將會導致誤解 /  190

Harel的分析 / 193

Jones的觀點—質量帶來生產率 / 199

那麼，生產率的情形如何 / 199

面向對像編程—這顆銅質子彈可以嗎 / 201

重用的情況怎樣 / 203

學習大量的詞彙—對軟件重用的一個可預見但還沒有被預言的問題 / 206

子彈的本質—形勢沒有發生改變 / 207

第18章     《人月神話》的觀點：是與非    /    209

第19章     20年後的《人月神話》     /    233

為什麼要出版20周年紀念版本 / 235

核心觀點—概念完整性和結構師 / 236

開發第二個繫統所引起的後果—盲目的功能和頻率猜測 / 238

圖形界面的成功 / 241

沒有構建舍棄原型—瀑布模型是錯誤的 / 245

增量開發模型更佳—漸進地精化 / 247

關於信息隱藏，Parnas是正確的，我是錯誤的 / 252

人月到底有多少神話色彩？Boehm的模型和數據 / 254

人就是一切(或者說，幾乎是一切) / 256

放棄權力的力量 / 257

最令人驚訝的新事物是什麼？數百萬的計算機 /  260

全新的軟件產業—塑料薄膜包裝的成品軟件 / 262

買來開發—使用塑料包裝的成品軟件包作為構件 / 265

軟件工程的狀態和未來 / 267

結束語   令人向往、激動人心和充滿樂趣的50年     /      269

譯後記  /      271

再讀軟件經典    如品陳年佳釀

《人月神話》是軟件工程領域絕無僅有的經典佳作，歷時近半個世紀，作者Fred Brooks對大型軟件項目管理的經驗思考啟迪了一代代工程師的實踐。

《人月神話》一書的開篇強調了構建“繫統產品”與構建“簡單程序”的任務不同。研發大型軟件繫統不是簡單程序的堆疊組裝。軟件開發任務不總是像收割麥子的任務一樣可分解，要分析問題性質以及子任務間的依賴關繫。軟件研發效能的量化估算不能對“人月”“人周”“人天”做簡單加法和乘法，正如不能基於個人百米成績來推算馬拉松成績一樣。新手培訓、溝通交互都會引入額外的成本，向延期的軟件項目添加新人會使項目拖得更久。軟件開發任務間復雜的依賴關繫需要科學管理，避免無效的人力投入。

軟件不可見性和抽像性是導致軟件復雜性的根本原因，也是軟件工程學科要應對的基本問題。軟件繫統的復雜性源於參與開發人員的概念模型是不完整和不一致的，正如“一千個人眼中有一千個哈姆雷特”，管理軟件項目的復雜性就需要達成各方對軟件繫統概念模型的局部完整性與一致性。軟件項目開發團隊的組織要融合開源、群智，以及規模化敏捷組織的最新理念，還要堅守外科手術團隊這樣的組織結構，持續優化大規模軟件繫統產品項目的組織與流程。

我國軟件產業規模已突破，成為軟件大國的同時還處在“大而不強”的困境，在繫統軟件與工業軟件領域還面臨著被“卡脖子”的風險。《人月神話》一書中的許多經驗、觀點對於我國關鍵基礎軟件技術、產品與產業創新發展具有重要指導意義。

今天作為數字經濟社會基礎設施的繫統軟件和工業軟件，都是經過數十年長期演進與發展的軟件，是軟件產業的根技術。如何改變這種受制於人的被動局面？我想在全力投入攻堅之外，還要深入思考、深入探究這類軟件產品工程研發的內在規律。實現軟件產業高質量發展的關鍵在於建立開發“能用、管用、好用”的關鍵繫統軟件和基礎工業軟件的工程方法與工具體繫。

軟件工程“沒有銀彈”的觀點還成立嗎？用“塑料薄膜包裝的成品軟件”無疑已成為歷史，但並不妨礙它當年為軟件產業發展帶來的積極貢獻與影響。進入軟件開源與大語言模型時代，軟件工程領域的“銀彈”是否已經出現？大語言模型在代碼輔助生成以及算法編程優化等方面展現出強大的能力，它會將軟件領域帶向何種高度？

再讀“人月神話”，今時今日又繪新意。軟件定義美好世界， 既是國家示範性軟件學院成立的初心，也是清華大學軟件學院在建院二十周年時對初心的再次表達。軟件繫統的形態，軟件工程的方法將在實踐者的持續探索和研究者的深入思考中不斷演進。

                                                                                             王建民    清華大學軟件學院院長

                                                                                                     2023年6月

★今天，《人月神話》依然活躍在軟件開發各個領域的話題中！我國軟件產業規模已突破，成為軟件大國的同時還處在“大而不強”的困境，在繫統軟件與工業軟件領域還面臨著被“卡脖子”的風險。《人月神話》一書中的許多經驗、觀點對於我國關鍵基礎軟件技術、產品與產業創新發展具有重要指導意義。
——清華大學軟件學院院長 王建民

★一些語言老去並消失，一些語言卻長存。C和Lisp比SQL要老，但它們也不會那麼快離開我們。……Fred Brooks警告我們，不要期望軟件開發會有“銀彈”，意思是，不要期望單個新技術能提供指數級的改進。
——Pro Oracle SQL Development（《Oracle SQL開發進階》）
APress出版社，2023

★把團隊分為Ops/platform/ML工程團隊……會帶來溝通和協作的成本。正如Frederick P.Brooks所說，一個程序員一個月能做的事情，兩個程序員要做兩個月。
——Designing Machine Learning Systems（《設計機器學習繫統》）
O'Reitty出版社，2022

★對防御性編程來說，一個根本的、不容更改的事實是：軟件充滿了缺陷，越是復雜的軟件，bug越多。《人月神話》的作者Frederick Brooks對大型復雜繫統做了很多的觀察。
——Beginning Rust Programming（《Rust編程入門》）
Wiley出版社，2021