臨近考試周，這裡我通過平時閱讀的《人月神話》十九個章節和知乎、簡書等網頁中網友們對《人月神話》的讀後感，對書中各個章節進行簡單的總結，以下均為個人手打觀點的思考與整合，僅供大家參考。

       乍一看書名，人月？什麼是人月？並非我第一下所想到的超級賽亞人看到月亮時的情景。人月是在估計和進度安排中使用的工作量單位。每個每月的工作量，這和我在公司實習中在系統中統計外包人員UT數量的性質相同。

      書中作者的觀點是，用人月來衡量一項工作的規模是一個危險和帶有欺騙性的神話。它暗示著人員數量和時間是可以相互替換的，人數和時間的互換僅僅適用於某個任務可以分解給參與人員，並且他們之間不需要相互的交流的情況。下面讓我們進入各個章節來看看作者所想表達的觀點。

第0章 焦油坑

      這裡，我們沿用夢斷程式碼給目錄編輯的方式，以程式設計師的習慣，將其稱為第0章。開篇以焦油坑為題，讓人聯想到了史前巨獸在焦油坑中垂死掙扎的震撼場景，也同樣暗示了過去幾十年來大型系統開發猶如焦油坑一樣，各種問題糾結在一起，讓人越陷越深，沒有辦法看清事情的本質。

      作者認為程式設計系統產品開發的工作量是供個人使用的、獨立開發的構件程式的九倍。如下圖所示，普通程式要想成為真正有用的程式設計系統產品，可以通過成為橫向功能上相互協作的程式設計系統和縱向通用的程式設計產品來實現，而程式設計代價均為3倍於原來的程式設計。

圖1 程式設計系統產品的演進

      程式設計這一職業同樣也是有樂趣和苦惱的，程式設計師，就像詩人一樣，幾乎僅僅工作在單純的思考中。程式設計師憑空運用自己的想象，來建造自己的“城堡”。這個觀點與《黑客與畫家》中的觀點不謀而合，後者把程式設計師的工作看成和畫家、作家一樣的類似。但是也正因為程式設計師所做的工作是純粹的智力創造，不斷的推倒重來就成為常態。概念設計上的不完善，使得軟體架構變得越來越龐大、複雜並且難以為繼，成為一個焦油坑，越是掙扎，越是深陷其中。

第1章 人月神話

      在眾多軟體專案中，缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來的影響還大。這些原因在於我們美好的假設（過於樂觀）、將進度和工作量混淆、過高的估算、缺乏跟蹤和監督、進度落後時下意識的增派人手。

      所以問題的關鍵是，如何使得專案進度不落後；要想使得專案進度不落後，就要制定出合理的專案進度。故問題又可以稱為如何制定出合理的專案進度。這裡作者給出了自己多年的經驗法則：“1/3計劃+1/6編碼+1/4構建測試和早期系統測試+1/4系統測試，所有的構建已完成”。充足的測試時間和僅僅1/6的編碼時間，這與我們大多數新人的觀念大相徑庭，很多時候我們常常認為編碼時間就是全部的時間了，難怪會導致進度落後。

      對於課上“如何理解Brooks法則”，書中也給出了相應的解答：專案的時間依賴於順序上的限制，人員的數量依賴於單個子任務的數量。從這兩個數值可以推算出進度時間表，該表安排的人員較少，花費的時間較長（唯一的風險是產品可能會過時）。相反，分派較多的人手，計劃較短的時間，將無法得到可行的進度表。

      此外，向軟體專案中增派人手從三個方面增加了專案必要的總體工作量：任務重新分配本身和所造成的工作中斷；培訓新人員；額外的相互溝通。

第2章 外科手術隊伍

      接著上一章的話題，需要協作溝通的人員的數量影響著開發成本，因為成本的主要組成部分是相互的溝通和交流，以及更正溝通不當所引起的不良結果（系統除錯）。因此係統應該由儘可能少的人員來開發，Mills建議大型專案的每一個部分由一個團隊解決，該隊伍以類似外科手術的方式組建，而並非一擁而上。也就是說，由一個人來進行問題的分解，其他人給予他所需要的支援，以提高效率和生產力。

      外科手術隊伍的成員組成如下：

      1.外科醫生：首席程度員，天分、經驗、能力；

      2.副手：外科醫生的後備，較少的經驗；

      3.管理員：控制財務、人員、工作地點安排和機器的專業管理人員；

      4.編輯：分析重組開發文件；

      5.兩個祕書：管理員和編輯每人需要一個祕書；

      6.程式職員：維護程式設計產品庫中所有團隊的技術記錄；

      7.工具維護人員：保證所有基本服務的可靠性，以及承擔團隊成員所需要的特殊工具的構建、維護和升級責任；

      8.測試人員：大量合適的測試用例，搭建測試平臺；

      9.語言專家：尋找合適的程式語言。

圖2 10人程式開發隊伍的溝通模式

      在具體運作中，首先，外科醫生和副手都瞭解所有的設計和全部的程式碼，保證了工作概念上的完整性。其次，在外科手術團隊中，不存在利益的差別，觀點的不一致由外科醫生單方面來統一。最後，團隊中剩餘人員職能的專業化分工是高效的關鍵，它使成員之間採用非常簡單的交流模式成為可能，即所謂的專業的事交給專業的人來完成。

      對於這樣的團隊的擴充套件，若要實現一個200人來解決的問題，我們僅僅需要協調20個人，即這20個“外科醫生”，藉助他們的思路來保證大型程式部分概念的完整性。

第3章 貴族專制、民主政治和系統設計

      作者借歐洲教堂風格的完整性，來表達了自己在系統設計中的主張：“概念完整性應該是最重要的考慮因素”。

      為了實現概念完整性，在軟體體系結構設計的時候必須實行貴族專制，讓少數的架構師來決定整體的架構，普通程式設計師毫無發言權。但是Brooks為了安慰那些可憐的普通程式設計師，說道：其實實現細節也是需要一樣的創造性、同樣的新思路和卓越的才華。但是誰都知道，如果能夠成為貴族，為何要在製造工藝上費勁心思呢？

      總結一下，作者認為設計由一個人或者具有共識的小型團隊來完成更能夠活得概念的完整性，對於大型的專案，可以將設計方法、體系結構方面的工作與具體實現相分離，將體系結構、設計實現、物理實現的諸多工作併發進行。

第4章 畫蛇添足

      本章主要講述的是結構師需要認識到第二個系統的風險，從而少犯錯誤。這是因為，在開發第一個系統時，結構師傾向於精煉和簡潔。他知道自己對正在進行的任務不夠了解，所以他會謹慎仔細地工作。第二個系統則是設計師們所設計的最危險的系統（可能是過分的設計）。而當他著手第三個或第四個系統時，先前的經驗會相互驗證，得到此類系統通用特性的判斷，而且系統之間的差異會幫助他識別出經驗中不夠通用的部分。

      結構師無法跳過第二次系統，但是他可以有意識的關注那些系統的特殊危險，運用特別的自我約束準則和設計理念、目的的變更，來儘可能避免畫蛇添足的後果。結構師必須堅持至少擁有兩個系統以上開發經驗結構師的決定。同時，保持對特殊誘惑的警覺，他可以不斷提出正確的問題，確保原則上的概念和目標在詳細設計中得到完整的體現。

第5章 貫徹執行

      假設一個專案經理已經擁有行事規範的結構師和許多程式設計實現人員，那麼，接下來，他需要做的是如何確保每個人聽從、理解並實現自己作為結構師的決策。

      手冊、或者書面規格說明，是一個非常必要的工具，儘管光有文件是不夠的。手冊是產品的 外部 規格說明，它描述和規定了使用者所見的每一個細節；同樣的，它也是結構師主要的工作產物。隨著使用者和實現人員反饋的增加，規格說明也在不斷地被完善。

      這裡再次強調了一致性的重要：即使是大型的設計團隊，設計結果也必須由一個或兩個人來完成，以確保這些決定是一致的，同樣地，必須明確定義體系結構中與先前定義不同的地方，重新定義的詳細程度應該與原先的說明一致。出於精確性的考慮，我們需要形式化的設計定義，利用記敘性定義來加深理解。允許體系結構師對實現人員的詢問做出電話應答解釋也是非常重要的，並且必須進行日誌記錄和整理髮布。最後一個建議是，專案經理最好的朋友就是他每天要面對的敵人——獨立的產品測試機構/小組，他們是使用者的代理人，專門尋找缺陷。設立測試小組是使設計決策得以貫徹執行的必要手段，同樣也是需要儘早著手，與設計同時實施的重要環節。

第6章 為什麼巴比倫塔會失敗

      據《創世紀》記載，巴比倫塔是人類繼諾亞方舟之後的第二大工程壯舉，但巴比倫塔同時也是第一個徹底失敗的工程，而其失敗的原因是缺乏交流和組織。

一個程式設計專案中同樣會出現這樣的問題，開發團隊應該以儘可能多的方式進行相互之間的交流：非正式、常規專案會議，會上進行簡要的技術陳述、共享的正式專案工作手冊。

      團隊組織的目的是減少不必要交流和合作的數量，因此良好的團隊組織是解決上述交流問題的關鍵措施。這裡給出如果專案有 n 個工作人員，則有（n^2 - n）/ 2 個相互交流的介面，有將近 2^n個必須合作的潛在團隊。而減少交流的方法是人力劃分和限定職責範圍。交流和交流的結果——組織，是成功的關鍵，交流和組織的技能需要管理者（這裡建議為產品負責人）仔細考慮，相關經驗的積累和能力的提高同軟體技術本身一樣重要

第7章 胸有成竹

      本章只解決一個問題：一個程式設計師的生產效率究竟有多高？首先，作者明確了估計的兩個要點，一是僅僅通過對編碼部分的估計，然後乘以任務其他部分的相對係數，是無法得出對整項工作的精確估計的；二是構建獨立小型程式的資料不適用於程式設計系統專案。對此，作者指出了工作量和程式碼行數不是線性關係，而是指數關係：工作量＝（常數）×（指令的數量）^1.5。文中又給出了Portman的資料、Aron的資料、Harr的資料、OS/360的資料和Corbato的資料，這裡就不一一列舉了。

      總結以下上述資料的結論：

      1.對於常用程式設計語句而言，生產率似乎是固定的。這個固定的生產率包括了程式設計中需要註釋，並可能存在錯誤的情況；

      2.生產率隨著系統複雜性或者難度增加而降低；

      3.使用適當的高階語言，程式設計的生產率可以提高5倍。

第8章 削足適履

      這一章主要是要解決專案投資與磁碟空間和記憶體之間的矛盾，但是這個矛盾在電腦硬體發展到現在的層次已經可以忽略掉了。

第9章 提綱挈領

      技術、周邊組織機構、行業傳統等若干因素湊在一起，定義了專案必須準備的一些文書工作。而這對一個新任命的專案經理來說是一大難題，這些文件的某些部分包含和表達了一些管理方面的工作。

      本章通過對比計算機產品的文件、大學科系的文件、軟體專案的文件，進一步闡釋了為什麼要有正式的文件。軟體專案的要求包括目標、使用者手冊、內部文件、進度、預算、組織機構圖和工作空間分配。即使是小型專案，專案經理也應該在專案早期規範化上述的一系列文件。

一個正式的文件能夠明確團隊中的分歧和矛盾、作為同其他人的溝通渠道、作為資料基礎和檢查列表，通過遵循文件開展工作，專案經理能更清晰和快速地設定自己的方向。

      本次讀後感先寫到《人月神話》中的前十章，明天再繼續整理出剩餘的九章內容，與同學們共同學習、進步。