在研究生期間我們的課程設定中有一門必修課程是軟體工程，其中有一個作業是讀人月神話並寫一篇讀後感。雖然我本科的專業是偏向於網路工程，並且我們也開設過軟體工程這門課。但是對於像我這樣的二流選手，在本科期間基本沒有認真學習，並且在大二後半年（2013.8月份）就開始接觸學習程式設計，但真正通讀過的程式設計書籍還是比較少的，所以這次還是鼓起勇氣抽時間把這本軟體工程中的鉅著粗讀了一番。言歸正傳，其實作者在這本書中“《人月神話》的觀點：是或非？”部分對本書進行了高度的概括，我想還是過一下我自己的大腦，接下來談一下我個人的感受吧！

    其實整本書分為16個部分我們還是按照每部分進行解讀，以防我們遺漏了某些知識從而造成我們一些思想的空白。

第一章焦油坑

    本書的第一章是焦油坑，在開始部分主要是介紹了系統產品比獨立構件開發難度大很多，接著表達了我們在程式設計過程的樂趣在於不斷的學習新的知識以及創造出對別人有用的產品，最後也說出了我們的苦惱在於追求完美但又在依賴於別人的原始碼中煎熬！

第二章人月神話

    本書的第二章是人月神話，該部分主要是講述了人員數量和專案時間進度的辯證關係。其中大家熟知的Brook法則：像進度落後的專案中增加人手只會使進度進度更加落後，這主要的增加的這部分人員需要與別人進行溝通交流，這其中會消耗很長的時間。

第三章外科手術隊伍

    本書的第三章是外科手術隊伍，首先作者肯定了小型精幹隊伍是最好的，但是這樣的隊伍開發大型系統太慢了，接下來作者提出瞭解決的辦法就是外科手術隊伍即由一位首席程式設計師來對系統進行整個產品的架構，其他多位程式設計師來進行協助工作，就是分工明確，各在其位各盡其能。

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

    本書的第四章是貴族專制、民主政治和系統設計，該部分主要是講解了概念完整性在系統設計中的重要作用。貴族專制統治提供概念完整性這並沒有扼殺了小組實現的創造性反而可以促進系統開發和測試的速度。另外作者提出了體系結構（ architecture）、 設計實現（ implementation）、 物理實現（ realization）的許多工作可以併發進行的觀點。

第五章畫蛇添足

    本書的第五章是畫蛇添足，在這部分作者主要說明了結構師和開發人員之間的責任分工。結構師必須為每一種建議準備一種實現方法，但不要過多的參與開發人員在實現的創造性，也應該虛心聽取開發人員對體系架構的建議。在這個章節中作業也暗示了第二個系統是人們所設計的最危險的系統，希望設計者不要過多的注重裝飾，不要由於做作而使系統很危險。

第六章貫徹執行

    本書的第六章是貫徹執行，在這個部分中作者主要講述的是在系統開發過程中溝通的問題。即使是對於大型的設計團隊也應該由一個或兩個骨幹對系統的整體架構做一致性的決策以保證概念的完整性。接著作者提及了文件的規格說明，以及形式化定義記敘性定義一者作為標準另一種作為輔助的關係。最後闡述了結構師與實現人員以及專案經理和測試小組之間應有的合適關係和溝通方式。

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

    本書的第七章是為什麼巴比倫塔會失敗？作者一上來就提出了這麼一個發人思考的問題，並給出了正確的答案就是就是缺乏交流，於是引出了本章的重點那就是組織。一個是專案工作手冊，即對專案必須產生的一系列文件進行組織的一種結構，前面先提及了每一個團隊成員應該瞭解所有的材料，後面又講解了每個人看到每件事的目標是錯誤的，我們只需瞭解介面，這是解決災難的處方。另一個是組織架構，團隊組織的目標是為了減少必要的交流和協作量，然而傳統的樹狀結構（權利結構的原理）是不友好的，應該調整為網狀結構這樣可以克服交流缺乏的困難。最後作者認為每個子專案應該具有兩個領導角色，一個產品負責人另一個技術主管或結構師，這兩個角色的任意組合是非常有效的。

第八章胸有成竹

    本書的第八章是胸有成竹，作者開頭就否定了對整體專案的精確估計不能通過對編碼部分的估計乘以任務其他部分的相對係數。之後通過幾個例子說明了生產率的問題，也提出當使用適當的高階語言時，程式編制的生產率可以提高 5 倍。

第九章削足適履

    本書的第九章是削足適履，該部分主要講解了程式對寶貴記憶體的精心利用與多磁碟訪問次數的控制，這主要依賴於區域性優化、使用者體驗、時間空間的折衷、程式設計技術的積累、新型演算法和資料的表現形式。

第十章提綱挈領

    本書的第十章是提綱挈領，本章主要講述了專案經理應該在專案早期規範化的一系列提綱挈領的文件，其中軟體專案的關鍵文件包括目標、使用者手冊、內部文件、進度、預算、組織結構圖和工作空間分配。另外還強調專案經理的主要日常工作是溝通， 而不是做出決定； 文件使各項計劃和決策在整個團隊範圍內得到交流。

第十一章未雨綢繆

    本書的第十一章是未雨綢繆，作者首先講述了將開發的第一個系統——丟棄原型——釋出給使用者對使用者、開發人員和產品都是一種摧殘，接著主要解說了三個部分，第一部分是為變更計劃組織架構，該部分主要說明老闆應該極力培養技術和管理之間自由分配的人手，對於兩條晉升線的高效組織機構建立同等的威信的比較困難的，組建外科手術隊伍式的軟體開發團隊是對上述問題所有方面的徹底衝擊，但這的確是一個長期行之有效的解決方案。第二部分是前進兩部，後退一步--程式維護，這部分主要是講解了程式維護的困難以及一些技巧，即在每次修復之後， 必須重新執行先前所有的測試用例， 從而確保系統不會以更隱蔽的方式被破壞。能消除、至少是能指明副作用的程式設計方法，對維護成本有很大的影響。同樣，設計實現的人員越少、介面越少，產生的錯誤也就越少。第三部分是前進一步，後退一步--系統熵隨時間的變化，這部分主要說明了系統的複雜度，即模組數隨著系統版本號呈線性增加而影響的模組以版本號的指數增加，所有的修改都使系統更加複雜，增加了系統的混亂程度。

第十二章干將莫邪

    本書的第十二章是干將莫邪，在這一部分中主要講述了一套通用工具的開發分配資源應該由專案經理制定，系統除錯大部分在夜間完成，一次分配給某個小組連續的目標時間塊是最好的安排方法，自頂向下、 徹底地開發一個性能模擬裝置應該儘早開始等觀點。接著說明了高階語言應用廣泛提升了生產率改進了除錯。最後提及了系統軟體開發中互動式程式設計的生產率至少是原來的兩倍。

第十三章整體部分

    本書的第十三章是整體部分，在這一部分作者首先強調了精確定義整體部分的重要性，在編寫任何程式碼之前， 規格說明必須提交給測試小組， 以詳細地檢查說明的完整性和明確性，以及說明了Wirth 的自頂向下進行設計新型軟體開發方法，但我們的思想也不能被其禁錮，有時必須回退，推翻頂層設計，重新開始。開發大量的輔助除錯平臺（ scaffolding 腳手架） 和測試程式碼是很值得的。必須有人對變更進行控制和文件化。系統測試期間，我們應該一次只新增一個構件。

第十四章禍起蕭牆

    本書的第十四章是禍起蕭牆，這一章節作者先討論了專案延遲是難以識別、 更不容易防範和更加難以彌補的。進取是軟體開發團隊比不可少的必要品德。PERT 的準備工作是 PERT 圖使用中最有價值的部分。 它包括了整個網狀結構的展開、 任務之間依賴關係的識別、 各個任務鏈的估計。 這些都要求在專案早期進行非常專業的計劃。接著論述了老闆和經理之間的對決。最後強調了評審機制和里程碑報告的重要性。

 第十五章另外一面

    本書的第十五章是另外一面，主要講述了文件在整個軟體開發中發揮的重要角色。文件能在整個生命週期對克服懶惰和進度的壓力起促進激勵作用。將文件合併至源程式是至關重要的。程式修改人員所使用的文件中， 除了描述事情如何以外， 還應闡述它為什麼那樣。對於加深理解， 目的是非常關鍵的，但即使是高階語言的語法，也不能表達目的。

20年後的人月神話

    最後一部分就是20年後的人月神話，這一部分的核心觀點是概念完整性和結構師。概念完整性即我們必須給使用者提供一個條理分明的概念模型， 這個模型描述了應用、 實現應用的方法以及用來指明操作和各種引數的使用者介面使用策略。結構師負責產品所有方面的概念完整性， 這些是使用者能實際感受到的。 主結構師開發用於向用戶解釋使用的產品概念模型，概念模型包括所有功能的詳細說明以及呼叫和控制的方法，其他結構師根據需要重複遞迴地進行，我們需要特別清醒的就是概念完整性是產品質量的核心。