這本書絕對稱得上在軟體工程領域的著作，作為軟體開發人員，低頭敲程式碼趕專案時，也要抬頭看一看。在軟體工程領域中，還存在很多程式碼解決不了的問題。
先借鑑百度百科的話，等整書讀完了，再自己總結。

《人月神話》探索了達成一致性的困難和解決的方法，並探討了軟體工程管理的其他方面。在《人月神話（英文版）》中，既有很多發人深省的觀點，又有大量軟體工程的實踐，為每個複雜專案的管理者給出了自己的真知灼見大型程式設計專案深受由於人力劃分產生的管理問題的困擾，保持產品本身的概念完整性是一個至關重要的需求。《人月神話(英文版)》適合任何軟體開發行業的從業人員閱讀，對軟體開發人員、軟體專案經理、系統分析師更是必讀之作。

第一章——焦油坑

以焦油坑為例，類比了軟體開發團隊，在產品開發過程中一般都會出現的問題。經過數月開發，產品可以線上執行，但效果卻和最初立項時目標甚遠，不能滿足需求。即使開發團隊再掙扎，加班也好，加人也好，都無法解決問題，像陷在焦油坑裡，越掙扎陷得越深。
以筆者自身經歷：去年，我一直在參與公司的平臺專案，經過一年的開發，產品功能很全，單獨線上執行沒問題。可它卻背離的初衷-其它產品線能力共享，開箱即用。結果產品線都沒有辦法使用，為達目的又投入了大量人力，可效果微乎其微。
程式設計的快樂
1.創造事物的快樂，從無到有。
2.成果能給他人帶來幫助，樂於分享。
3.多個程式組個一個系統，並以精妙的方式執行，增加成就感

第二章——人月神話

在軟體專案中，缺乏合理的進度安排是造成專案延期的最主要原因，它比其它所有因素加起來的影響還要大。現在我們可能感受不深，看完下面作者的解讀，才恍然大悟。不得不佩服作者的功力。
作者總結的原因我簡單概括下：

1. 對技術缺乏有效的研究，產生一種不真實的設想——一切都將運作良好。每一項任務僅僅花費它所“應該”花費的時間。程式設計人員通過非常純粹的思維活動來開發程式，期待在實現過程中不會碰到困難
   。
   （實際在開發中，往往會遇到很多問題，在實現細節環節最為明顯，即便是相似的業務，可能還會遇到坑）
2. 以謬誤的思考方式，在估計和進度安排中使用工作量單位：人月
   書作者總結了四種關於人數和時間的轉換關係曲線,自己又簡單的化了下增加理解
   
   從圖中可以清晰的看到，人月跟任務型別有著密切的關係。所以用人月來評估開發的工時，是不準確的。加人≠加生產力
3. 系統測試的進度安排常常是程式設計中最不合理的部分。由於開發者的樂觀主意，通常實際出現的缺陷數量要比預料的多得多。根據自身的開發經驗，在系統測試中暴漏的問題都太好排查和解決，要花費更多的時間。
4. **空乏的估算，缺少資料的支援，完全憑軟體經理的直覺。**為了滿足客戶期望的日期而造成不合理的進度安排，在軟體工程領域最為普遍。（ps：天天加班加班，好像就是這麼來的 - - ||）
5. 重複產生的進度災難。當一個軟體專案落後於進度時，最普遍的做法就是加派人手。作者引用了Brooks法則，還印證這個不合理的做法。向進度落後的專案加派人手，只會是進度更加落後。