《人月神話》二十年

一本為何能活二十年的書#

《人月神話》自 1975 年出版以來，成為軟體工程領域被引用最多的著作。二十年後，Brooks 在這最後一章中回顧：為什麼一本討論 1960 年代 IBM 大型主機開發經驗的書，到了個人電腦與網際網路時代仍然被廣泛閱讀？

答案直指本書的核心：Brooks 討論的不是特定技術，而是人在建構複雜系統時面臨的根本挑戰。技術在二十年間翻天覆地，但人際溝通的困難、概念複雜度的管理、團隊協調的成本——這些問題的本質從未改變。

Brooks 指出一個看似矛盾的現象：硬體性能提升了數百萬倍，軟體工具不斷進化，但軟體專案失敗的根本原因在 1995 年與 1975 年驚人地相似。

Brooks 坦承，1975 年到 1995 年之間，計算的世界發生了革命性的變化：

這些變化每一項都深刻影響了軟體開發的實踐。然而，Brooks 指出一個關鍵的觀察：

**「軟體建構中最困難的部分，是決定要建什麼。」**這個論點在二十年後不僅成立，而且更加真實。

儘管技術環境天翻地覆，軟體工程的根本問題依然存在：

Brooks 承認，他在 1975 年最大的盲點是未能預見商業套裝軟體（Shrink-wrap Software）的革命。

在大型主機時代，幾乎所有軟體都是為特定組織量身訂做的。然而，個人電腦的普及創造了一個大眾市場——文書處理、試算表、資料庫、電子郵件——這些通用軟體的開發成本可以分攤到數百萬使用者身上。

「購買而非自建」（Buy vs. Build）從一個邊緣策略變成了主流做法。這可能是二十年間軟體產業中最重大的結構性變化。對大多數組織而言，使用現成的商業軟體遠比自行開發更經濟。

Brooks 在本章做出了他對原書最重要的修正：

原書暗示了一種順序式的開發流程——先定義需求、再設計架構、再編寫程式碼、最後測試。這基本上就是瀑布模型。二十年後，Brooks 明確否定了這個做法。

正確的方式是漸進式與迭代式開發：

Brooks 的原話值得重視：瀑布模型是錯誤的。在 1995 年，這是對當時仍被許多組織奉為標準的開發流程的直接挑戰。

Brooks 特別讚賞了微軟的**「每日建構」**（Daily Build）實踐：每天晚上將整個系統重新編譯一次，運行自動化測試，確保系統始終處於可運行狀態。

這個做法體現了漸進式開發的精神：

Brooks 在 1995 年讚賞的「每日建構」，到了今天已經演化為持續整合與持續交付（CI/CD），成為現代軟體開發的標準實踐。

Brooks 再次強調軟體重用是提升生產力最有希望的途徑。不是重用程式碼片段，而是重用完整的元件、函式庫和框架。

關鍵的洞察是：每一個你不需要自己建構的元件，都省去了它所有的設計、實作、測試和維護成本。隨著元件生態系統的成熟，這種累積效應可能非常可觀。

Brooks 在全書的最後，回到了他最根本的信念：

偉大的軟體來自偉大的人。

沒有任何流程、工具或方法論可以取代優秀人才的價值。組織應該將最大的投資放在：

軟體工程的歷史一再證明：一小群優秀的人勝過一大群平庸的人。這是 Brooks 定律的另一面——與其在延遲的專案上加人，不如一開始就用對的人。

Brooks 以一段近乎哲學性的反思結束全書。軟體工程在本質上是一門關於人的學問。我們建構的是抽象的概念結構，而概念的複雜性源自我們試圖解決的問題本身。工具會進步，語言會演化，硬體會更新，但人腦處理複雜性的能力有其極限，人與人之間溝通的代價不可消除。

這就是為什麼《人月神話》在二十年後仍然有意義——它討論的是軟體工程中不會改變的那些東西。