《人月神話》是大學剛開始就很熟悉的一本書，似乎都要在書架上擺上它才能表明軟體工程學生的身份。時至今日我再讀它，因為有了系統開發的經驗，很多的內容都通過記憶得到了驗證，讀來與大一時的「雖然不懂你在講什麼但好像很有道理」 的體會有了明顯的不同。這裡選擇一些感觸較深的章節寫一些自己的理解。
焦油坑
入坑前，都會覺得自己戰無不勝，就像陷入焦油坑的巨獸，自以為有著龐大的身軀就能在各種的地形中安然度過。在填寫志願的時候，對未來充滿希望的孩子們還不知道自己將面臨什麼，只覺得**的世界奇妙酷炫，然而**對於軟體系統的開發來說只是水面上的冰山。前人的智慧型告訴我們如果沒有認真地進行分析、設計、進度計畫，真正開始開發後總會讓自己陷入令人痛苦的麻煩。事實上，這種麻煩在我前期做過的絕大多數專案中都出現了，但是當你咬著牙從中脫身，還是會體驗到創造與實現的快樂，通過這些經歷和課程學習，我也慢慢能總結歸納經驗教訓，讓自己今後能盡量少地陷入這樣的「焦油坑」中。
畫蛇添足
過度設計的現象常常存在，據我的觀察，這種現象往往出現於極度追求完美的人和剛剛經歷過首次開發設計不足的經驗教訓的人。過度設計的系統在最初就引入了過多的複雜性，導致開發舉步維艱，這個問題或許在乙個架構師有了一定經歷後就自然能夠解決，但是「第二個系統」的困境出現時，我們可以有意識地約束自己做出一些捨棄。
為什麼巴比倫塔會失敗
巴比倫塔的製造是乙個神話故事，但是其中的道理卻對今天人們的協作有著重要的啟示。軟體系統的開發完全通過計算機執行，為什麼還是很少有遠端協作的企業，這是因為遠端協作很容易導致交流的缺失。大型的軟體專案開發需要團隊中的每個人能及時了解到整個團隊在做些什麼，這就需要經常的交流。交流的方式可以通過非正式的**、網路，也需要正式的會議和工作手冊。
提綱挈領
我們做課程作業時往往需要交大量的文件，而我們在寫這些文件時就像填充八股文一樣只考慮制式而放棄了思考為什麼要將它放在文件中。設計與決策的書面記錄是必要的，但是文件存在的本意是為了溝通，我們寫文件時應該考慮文件內容的現實指導意義，建立功能劃分明確的文件型別和邏輯清晰的文件結構。
未雨綢繆
我們在實現功能時往往有很多思路，但是哪種思路能行得通並且最適合情況就需要我們進行試驗性開發。試驗性開發確實會造成精力的消耗，或許大量的測試方案最終還會被捨棄，但是我們必須這樣做。實際上如果不進行方案的實驗，正式的開發反而可能遭遇返工和混亂的拆補，會嚴重分散重新開發人員的精力和信心，甚至影響使用者對產品的信任。這世界上唯一不變的就是變化本身，我們必須有未雨綢繆的能力，對未來可能產生的變化做出提前的設計，甚至對組織架構也需要進行提前的計畫來規避變化造成的風險。前人的智慧型告訴我們，缺陷是永遠存在的，我們需要通過質量管理放緩系統混亂度的提高。
整體部分
物件導向程式設計的「封裝」思想和結構化程式設計的「精化」思想對於整個軟體開發過程的各個粒度同樣適用。整體的順利執行離不開各個組成部分的優化。編碼時各個資訊隱藏的模組需要完成各自的任務，再通過介面互相配合。測試時需要從最小的單元測試開始，每一粒度都測試完全時，整個系統的執行才***。當系統出現問題，需要找到問題的發生點，這時就需要將問題在不同的模組和粒度上分解測試，最終找到問題的癥結。
人月是乙個神話，現如今軟體工程卻是真實地在解決軟體過程中的問題，提高軟體產品的質量。研究人員和實踐人員的不斷探索或許永遠無法一勞永逸地解決所有問題，但是從中積累地經驗卻能夠有效地指導我們更好地應對大型軟體系統的實現與管理。
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...
人月神話讀後感
人月神話 這本書風行已經很久了，寫成於1975年，經歷這麼久的時間，在當前又重新流行，讓我很驚訝,但是一直沒有時間讀。今天突然想起自己的機器上有本拷貝別人的電子書，決定讀讀。我今天只看了兩章，即焦油坑和人月神話。人月神話看上去這麼浪漫的名字，原來並不是真的說神話故事，作者闡述的主要觀點是在軟體開發專...
《人月神話 》讀後感
之前一直聽老師講 人月神話 彷彿這就是乙個傳奇。百聞不如一見，在這本300多頁 中文新版 的神書，在經過了20多年的歷史之後，仍然暢銷不衰，究竟是什麼讓它有如此的魅力？過去的乙個月，一點一滴的閱讀之中算是初步的了解到了它的一部分吧。人月神話的核心觀點 概念完整性和架構師 brooks認為，乙個整潔 ...