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