焦油坑的意思說明了即使你足夠強大，也無法擺脫束搏而沉到坑底。感覺用這個比喻來形容軟件開發再合適不過了。當軟件產品的規模增加的時候，復雜度成倍增長，從而導致這些要素之間不是單純的線性關系，這是人月神話的啟示之一；同時由于軟件項目本身的生命周期模型和工序任務限制，導致對于一定規模的軟件產品研發，無論投入多少的資源，都有一個最短工期的限制，在這個最短工期下投入再多的資源也沒有用。

?職業的樂趣

? ? （1）創建事物的純粹快樂

? ? （2）開發出對他人有用的東西

? ? （3）整合零部件，收到預期效果

? ? （4）學習的樂趣

? ? （5）像詩人一樣創造的樂趣

職業的苦惱

? ?（1）追求完美

? ?（2）由他人來設定目標，供給資源，提供信息

? ?（3）尋找瑣碎的bug

? ?（4）調試和查錯往往是線性收斂的?

? ?（5）產品在即將完成或者終于完成的時候， 卻已顯得陳舊過時

這， 就是編程。 一個許多人痛苦掙扎的焦油坑以及一種樂趣和苦惱共存的創造性活動。

?

向進度落后的項目中增加人手，只會使進度更加落后。 -Brooks法則

　　這是這本書給我印象最深的一句話，也是本書的核心觀點之一。雖然乍一看很反直覺，但卻又是如此契合軟件開發的現實情況。一方面，部分任務由于次序上的限制不能分解，人手的添加對進度沒有幫助。 另一方面，即使是可分解的任務，子任務間需要相互溝通和交流，增加了培訓和相互交流的成本。

樂觀主義

　　樂觀主義假設一切都會運轉良好，而不會遇到任何的風險和問題，這是程序員的通病，對項目盲目的樂觀，而恰恰實際情況是在實際開發中遇到一個疑難問題耽誤幾天或一周的時間。

人月神話

　　用人月來衡量一項工作的規模是一個危險和帶有欺騙性的神話，因為它暗示了人員數量和時間是可以相互替換的。

　　假設人月可以互換，則為了縮減周期需要投入更多的人，為了讓更多的人都有事可做就需要細分任務，細分任務自然增加了系統分解和后期集成的工作量，細分任務間無法避免的依賴和關聯自然增加了溝通的成本和工作量。而且由于任務的細分需要引入文檔等重量級的溝通工具，原始的需求信息在需求，設計，開發，測試等多個環節傳遞很難真正保證我們需要的概念完整性。

　　如果一個系統按功能點估算有200個功能點，按一個功能點200-300行代碼計算，整個系統規模在5萬行代碼左右。這是一個中小型的項目或系統。如果按照總生產率80行/天計算，則總工作量在20人月左右。根據非線性關系我們可以估計理想情況或者說性價比最好的情況是投入5人4個月完成，當人數增加一倍時候進度只能壓縮到3個月。當人數再增加到15個人的時候，進度壓縮到2個月，這個時候增加再多的人就已經沒有用了，對于這種規模的的系統，2個月可能就是進度極限了。

進度災難

　　除去了神話色彩的人月。項目的時間依賴于順序上的限制，人員的數量依賴于單個子任務的數量。從這兩個數值可以推算出進度時間表，該表安排的人員較少，花費的時間較長（唯一的風險是產品可能會過時）。相反，分派較多的人手，計劃較短的時間，將無法得到可行的進度表。總之，在眾多軟件項目中，缺乏合理的時間進度是造成項目滯后的最主要原因，它比其他所有因素加起來的影響還要大。

　　以上便是人月神話前兩章的要點整理，無怪乎這本書有如此高的評價，然文中提到的部分觀點自己沒有切身體會，但是能夠從整體上獲得對軟件項目有一個重新的認識。這本書在一些不涉及具體技術的方面，很有先見性和指導性，我想這也是這本書的普適性這么強的原因之一。

?

轉載于:https://www.cnblogs.com/birdcanfly/p/9692872.html

總結

以上是生活随笔為你收集整理的焦油坑和人月神话--人月笔记1的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。