The Mythical Man-Month 讀書筆記
The Mythical Man-Month被翻譯成了《人月神話》，初看此書名，還以爲是神話故事，再加上去圖書館借書時發現這本書擺放在XX北館四樓（社會科學圖書庫），還以爲自己檢索錯了。當找到書之後，看到了醒目的藍色封面，在封面上同時有中英文書名，還配有小字“40週年中文紀念版”和著者Brooks，才確定這就是我要找的The Mythical Man-Month的中文譯本。
借到這本書之後，先瀏覽了這本書的三篇序和目錄。三篇序依次是清華大學博士王計斌(Dave Wang)寫的代序，Brooks寫的20週年紀念版序言以及第一版序言。從王博士和Brooks自己的序言裏就可以感受到軟件工程一直面臨嚴峻的問題，以及這本小冊子的博大精深。這本小冊子歷經20年，40年，甚至到2018年的今天，一直繼續流行，作者傳達的觀點和工程經驗仍值得思考和借鑑。其實小冊子是王博士的叫法，我借到的這本譯本有369頁，完全沒法稱呼小冊子。翻閱目錄發現，其實除了正文，有近五十頁的附錄，附錄大多是對正文的書評。與書名一樣，每章的中文標題也充滿了神話色彩，這使我更加好奇正文裏到底寫了什麼神奇的故事。
這本書我花了大約一週的空閒時間纔讀完，包括書評。書中前15章分別從編程問題、時間進度、團隊組成、任務分配等不同角度分享了軟件開發遇到的問題以及相關經驗和解決之道。16章沒有銀彈 和17章 再論“沒有銀彈” 是對軟件工程中出現的困難的原因探究，不斷的思考何爲根本問題，何爲次要問題，進而探尋是否存在解決之道。18章內容是對第一版《人月神話》，也就是本書前15章的濃縮。19章20年後的《人月神話》增補了一些對軟件工程新的思考，對書中以前一些思考的對錯進行闡述和糾正。以下是我從Brooks前15章表達的內容裏獲得的經驗知識：
編程問題之“焦油坑”：編程系統軟件（Programming System Product）是真正有用的產品，是大多數系統開發的目標，但是編程系統軟件的成本卻出奇的高，是簡單程序的9倍。編程可以帶來創造新事物的快樂，也會被bug折磨，甚至有時在付出大量辛苦勞動之後發現產品顯得過時。
時間進度之“人月神話”：人月之所以是神話，是因爲人月作爲衡量一項工作的規模是危險的和帶有欺騙性的。增加人員未必會減少開發時間，人員的加入會增加更多的溝通工作量。溝通包括培訓和相互交流，惡劣情況下，增加的溝通負擔會超過任務分解產生的作用。作者認爲所有的編程人員都是樂觀主義者，而缺乏合理的進度安排是是項目之後的主要原因。
團隊組成之“外科手術團隊”：編程人員的水平相差很大，人員增加溝通又會增加工作量，出於效率和概念的完整性考慮，最好有小而精幹的隊伍設計和開發。但是對於大型系統團隊，“外科醫生-副手”團隊架構從效率、概念的完整性和開發週期而言，纔是可取的。“外科醫生”從上到下進行所有的設計，一絲不苟的專注於體系結構。
任務分配之“專制民主”：產品既要考慮成本和性能，也要實現易用性的目標。易用性通常需要結構師（外科醫生）實行“貴族專制統治”來實現，而成本性能很大程度依靠實現人員，實現小組施行“民主統治”，發揮小組的創造性。
混淆責任分工之“畫蛇添足”：結構師和開發人員要明確自己的任務分工。對於結構師，第二個系統往往是自己所設計的最危險的系統，原因通常會傾向於過度設計，畫蛇添足。
一致性之“貫徹執行”：對於大型團隊，設計結構要確保一致性。體系結構的定義應至少有兩種以上的實現，如使用形式化定義和記述性定義，必須選用一種作爲標準，一種輔助來加深理解。獨立的產品測試小組是保證一致性貫徹執行的必要保證。
導致“巴比倫塔”失敗的交流和組織：巴比倫塔爲什麼會失敗？一是缺乏交流，二是缺乏交流的結果——組織。大型項目中的交流有非正式途徑、會議和工作手冊。工作手冊應包括目的、外部規格說明、接口說明、技術標準、內部說明和備忘錄，對於團隊交流至關重要。良好的團隊組織的目的是要減少交流和協作量。
對生產率要“胸有成竹”：系統編程如何工作量如何估計？Brooks有兩條忠告，一是僅僅通過對編碼部分的估計，然後應用之前推薦的比率（計劃進度、編碼、構件測試和系統測試的比率），是無法得到對整個任務的估計的；二是，構建獨立小型程序的數據不適用於編程系統產品。Brooks對比多份數據，認爲對於常用的編程語句，生產率似乎是固定的，而且如果使用高級語言，編程的生產率會提高數倍。
規模(內存)之“削足適履”：規模是軟件系統產品用戶成本中很大的一個組成部分。開發人員必須設置規模的目標，控制規模，考慮減小規模的方法。在空間預算角度，Brooks分享了兩個技巧：用功能交換尺寸和考慮“空間-時間”的折中。數據的表現形式是編程的根本。
文檔之“提綱挈領”：爲什麼要用正式的文檔？1、書面記錄決策是必要的；2、文檔能夠作爲同其他人的溝通渠道；3、項目經理的文檔可以作爲數據基礎和檢查列表。項目經理的任務是制定計劃，並實現計劃。只有書面計劃是精確的和可以溝通的，而且通過遵循文檔開展工作，項目經理能更加清晰和快速的設定自己的方向。
面對變化之“未雨綢繆”：“實驗工廠”的存在，就是爲了捨棄而計劃的。變化是與生俱來的，所以要爲變更設計系統，爲變更計劃組織架構，考慮程序維護帶來的副作用。系統軟件開發是減少混亂度（減少熵）的過程，而軟件維護是提高混亂度（增加熵）的過程。
資源分配之“干將莫邪”：項目經理應該制定一套策略，爲通用工具的開發分配資源，同時還必須考慮專業工具的需求。
自上而下之整體部分：好的自上而下的設計可以從下面四個方面避免bug:1、清晰的結構和表達方式更容易對需求和模塊功能進行進行精確地描述；2、模塊分割和模塊獨立性避免了系統級的bug；3、細節的抑制使結構上的缺陷更容易識別；4、設計在每個精化步驟上都是可以測試的，所有測試可以儘早開始，而且每個步驟的重點可以放在合適的級別上。
計劃控制之“禍起蕭牆”： 項目一天一天的進度落後是難以識別的、不容易防範和難以彌補的。所以控制大型項目，需要制定嚴格的進度表，而且不能讓里程碑成爲沉重的負擔。如何讓里程碑發揮積極作用，就需要一線經理與老闆減少角色衝突和鼓勵狀態共享。老闆最好區分“狀態檢查”會議和“問題—行動”會議。
自文檔化之另外一面：Brooks提出的“合併文檔”，即將文檔整合到源程序，這能保證編程用戶方便、及時地得到文檔資料。這種程序被稱爲自文檔化（Self-Documenting）。在線系統的高級語言應該使用的工具中，自文檔化發現了它的絕佳應用和強大功能。
如果參與過軟件項目，一定會對Brooks前15章的內容有較多的體會，深知軟件工程是一個龐大、複雜而又抽象的實體。Brooks在No Silver Bullet（《沒有銀彈》）的討論中，用“人狼”（werewolf）來形容軟件項目的一些特性，來討論到底有沒有消滅“人狼”的“銀彈”。Brooks從技術爲核心的角度把軟件活動分成了根本任務和次要任務。根本任務是打造構成抽象軟件實體的複雜概念結構。現在軟件系統中存在着複雜度、一致性、可變性和不可見性這些無法規避的內在特性。這些特性決定着軟件開發的根本困難,Brooks對銀彈的存在一直持懷疑態度，認爲目前的一些突破只是在解決次要困難。到底有沒有銀彈，Cox從人爲核心的角度，得出了：銀彈是存在的，只不過是軟件思維的變遷（paradigm shift），而不是技術（technology）。兩位大師的出發角度不同，得出的結論相異，孰優孰劣，以我對軟件淺顯的理解，不妄加評論。但是，出於我對軟件工程美好的期望，如果存在必然是好事。
在 20年後的《人月神話》部分，Brooks思考着又經過的20年軟件的發展，對自己對軟件工程的見解重新回顧和反思。Brooks認爲，構造捨棄原型的建議是錯誤的，原因在於太過於簡單化了；增量開發模型有獨特的優點；Parnas對於信息隱藏的見解是對的。20年的發展，微型計算機普及了，軟件產業也發生變革了，軟件構件的使用逐漸流行了。軟件工程在不斷髮展，但Brooks認爲焦油坑將會繼續存在很長時間，軟件工程面臨的根本困難仍然沒有突破。
這本《人月神話》從1974年第一版到現在2018年，已經過去44個春秋，仍然在軟件行業繼續流行着。足以見得，有價值的思想經久不衰。最後，希望軟件工程繼續發展，不斷有所突破。
2018.09.23
參考文獻：
[1]Frederick P. Brooks, Jr. 著; 汪穎 譯. 人月神話[M]. 北京:清華大學出版社.2015