在《人月神話》中brooks大師用簡短的篇幅，描繪出整個程式世界的苦與樂。
」程式設計師都是樂觀的傢伙。「這點我可以從我身邊的同學身上看出來。我在做我們的團隊軟體的時候，大膽的壓縮時間，感覺這些技術都是信手拈來，然後在開始做的時候卻發現，在很多環節，也許就是乙個簡單的錯誤有可能耽誤我很長時間。也就應了」他們所犯的第乙個錯誤就是假設一切都會進行的很順利「。還記得當初tomcat超時，一開始不清楚是這裡出了問題，然後死活都不知道問題出來**。通過查資料等等途經才清楚是這裡出了問題。
」人月「二字，並非玩笑。之前沒有想過人月的關係，假如突然讓我承擔專案組長的職務，想必也會經歷很多挫折。作者在這裡設定了乙個前提，」使用人月必須要在人力與工時可以互換的狀況下，而且要當工作可以切割，投入工作的人不用溝通，人力與工時能互換「才能使乙個人做三十天與三十個人做一天的結果相同。這裡我要講講我對人月的理解，假如我自己做了整個軟體，在最後不能按時完成，那麼給我加派人手，我想最終也不能按時完成。因為技術很高的不會來幫我，技術一般的並不能按照我的思想快速的融入工作之中。
」外科手術團隊「就是軟體團隊就像手術團隊，分工明顯。大家各有所長，有領導者指引全域性，然後大家能夠有規律的完成自己的事。作為乙個團隊，在我們的開發中，顯然是按照模組分工，大家各自完成自己的任務。但是在最終軟體結合過程中，發現了有乙個總領全域性的人的重要性。就想《構建之法》中的pm。
這就是我閱讀過人月神話後結合自身經歷的讀後感。
人月神話閱讀筆記03
人月神話拜讀完了，真的感覺學到了很多，受益匪淺，書開始就形象有有趣的把軟體危機比作 焦油坑，交流至關重要，實踐是最好的老師，文件撰寫是軟體人的必修課，這本書讓我們對軟體工程有了更深一步的理解，有了全新的認識，軟體工程焦油坑在相當長時間內仍會存在，我們必須努力學習，不斷創新，獲得更大的進步。一 我過去...
人月神話閱讀筆記03
今天我閱讀的是貫徹執行一節。假設乙個專案經理已經擁有行事規範的結構師和許多程式設計實現人員，那麼他如何確保每個人聽從 理解並實現結構師的決策？對於乙個由 1000 人開發的系統，乙個 10 個結構師 的小組如何保持系統概念上的完整性？首先要有文件化的規格說明，即手冊。手冊或者書面規格說明，是乙個非常...
人月神話閱讀筆記03
人狼這種民間傳說中存在的怪物，會在月圓之夜由我們熟悉的人類面孔變成可怕的狼臉。我們熟悉的軟體專案也有著人狼的特性，看似簡單明瞭的外表，但是卻可能隨時變成乙個進度落後 超出預算 存在大量缺陷的怪物。在民間傳說中對付人狼唯一可靠的 就是銀彈。所以銀彈在軟體專案中就是比喻這種使得軟體成本像計算機硬體成本一...