讀了Brooks的《人月神話》一書，很有感觸，記錄下自己印象深刻的觀點並結合自己的職場經驗分析一下。
0. 人月神話
在閱讀《人月神話》之前，只理解“人月”是指項目時間安排的單位，沒太注意“神話”的含義。通讀了全文後，才懂了其中的見解：Brooks認爲，項目開發中，人和月是不能互換的，人和月互換就是個神話。1個人5個月的項目，5個人在一個月內一是完不成的，這個觀點基於的理由是：有些任務不能拆分，不能並行去進行，需要時序，需要過程。書中舉了一個通俗的例子：一個女人9個月可以孕育一個小孩，但是9個女人一個月不能孕育一個小孩，即闡明瞭任務的不可拆分性和不可並行性。
1. 數據結構設計是程序設計的中心環節
數據決定了數據結構，數據結構決定了程序邏輯
2.儘量少畫流程圖，多用敘述性文字表達
流程圖能夠直觀的顯示出程序運行的邏輯，前提是流程圖畫的比較細緻，否則還是需要文字描述輔助說明。但是繪製詳細流程圖需要大量的時間，尤其是遇到流程調整時，修改流程圖更是耗費時間。筆者就曾經在某個項目開發中，繪製了大量的流程圖（多個正常運行流程和多個異常流程的時序圖），耗費了將近兩天的時間。在後續的實現和調試過程中，優化和修改流程時，經常出現程序邏輯和文檔上的時序圖不一致的情況，影響了測試人員編寫測試用例，增加了開發和測試人員溝通的時間。因此，除了必要的整體架構圖和個別正常場景的時序圖之外，文檔中儘量使用文字描述代替流程圖。
《人月神話》中也提到，有時，很多必要的流程圖都是在程序開發好之後根據實現的邏輯補充上去的。筆者也有同樣經歷：在最終程序完成調試後，再次修訂文檔中的部分流程圖和邏輯。
3. 溝通最重要，可以在早期杜絕接口上的問題
現代社會的各種工作都是分工合作開發，軟件工程也是如此。不同的組件一般由不同的小組或同事開發，組件間按照定義的接口和交互流程協作完成整個軟件系統的功能。在實際工作中，經常遇到在系統測試時才發現組件間接口不一致或者交互流程存在缺陷，糾其原因，就是Brooks在《人月神話》中提到的溝通不及時的問題。筆者在工作中，由於前期流通不到位或者未同步到開發文檔中，經常導致類似的問題，如接口實現不同（如參數錯誤）、接口未實現或過度實現、兩邊理解的交互流程不一致等，導致後續調整和修改耗費了更多的時間，項目進度和質量難以保證。因此，要在早期溝通清楚，在各個問題上達成一致，形成標準文檔。在整個開發過程中，遇到問題也要及時溝通確認，不要理所當然的認爲應該是這樣或那樣，保證開發質量。
4. 項目延誤時，增派人手可能會適得其反
Brooks提出上述觀點主要基於兩個原由：一是新增加的人手需要培訓和學習，會增加溝通時間；二是有些任務不是並行的、是不可拆分的。新增加的人手如果不瞭解項目相關的概念和業務知識時，需要抽出部分原有項目人員對其進行培訓，這會耗費一定的時間，而在新手開發過程中遇到問題時，又需要老手抽出時間進行指導。正如Brooks所說，項目的延誤主要是源於項目進度安排的不合理導致，出現問題時，最好重新分析項目難度，重新安排項目進度。因此，儘可能不要向落後的項目增加人手，如果非要增加的話，選派那些有經驗的、熟悉項目業務知識的人員。
5. 在開發第二個系統時，容易陷入過度設計的麻煩
在開發第二個系統時，因爲有了第一個系統的經驗，所以會在需求要求的基本功能外，添加很多額外的功能，有些功能可能用戶很少會用到。由於這些過度的設計，增加了整個項目開發時間（包括設計、實現、測試、維護），甚至增加整個系統的複雜度和Bug出現的概率，最終延誤了產品的上線時間。筆者在工作中，也遇到過過度設計延誤項目進度的情形。在當今社會中，時間效率就是市場機會，就是金錢，因此，在設計軟件時，要減少不必要的設計，減少項目週期。
6. 軟件要由少數人完成結構（架構）設計來確保概念的完整性
由少數人來完成軟件架構設計，這樣可以保證各方面的一致性（包括接口定義、交互流程等）
7. 定期重構代碼，刪除無效的代碼
8. 程序、程序產品、程序系統是三個層次上的軟件開發。後者需要花費的時間是前者的3倍。程序是可運行的代碼
程序是指可運行的demo,而程序產品是在程序的基礎上增加了其它附屬的設計實現（接口優化、參數檢查、各種測試、文檔說明等），是產品級的程序。而程序系統又比程序產品提高了一個級別。因此程序開發可能1小時就能完成，但只能作爲內部少數人技術交流使用，如果要達到產品級別，需要花費更多的工作量
9. 進度安排中，1/3時間用於設計，1/6時間用於編碼，1/4時間用於單元組件測試，1/4時間用於系統集成測試
Brooks的觀點認爲，實現（編碼）在整個項目開發中，佔用的時間比重是最小的。在軟件開發中，架構設計的複雜度決定了編碼的工作量，優秀的架構設計使代碼邏輯更清晰，所需的代碼量更少。筆者在工作中也有同樣的體會：複雜的設計會導致混亂的實現，最終使測試工作也陷入麻煩。
在項目安排中，Brooks把一半的時間分配給了測試環節（包括單元組件測試和系統測試），這樣分配的理由是：某些設計問題和實現問題，只有經過測試才能發現。此時，如果需要調整設計的話，會耗費更多的時間。因此分配給測試環節的時間實際包含了再設計、再實現的部分，從而保證項目進度。
10. 新人開發新系統，老人維持舊系統
新、舊系統同時存在時，新系統最終會取代舊系統。舊系統一般相對於新系統會更混亂，更復雜，即Brooks提到的焦油坑。因此舊系統由原有人員進行維護，新人則直接加入新系統，避免陷入舊系統這個焦油坑，會更有助於整個團隊的建設和項目的開發。