作者在《人月神話》中對於大型專案總是陷入焦油坑的原因給出了一些令人嘆服的解釋，其中廣為流傳的就是「人月神話」。事實上，它的意思是：人月是乙個神話——通俗地講，人月，即工作人員和時間可以替換，二者是成反比例的思想是乙個一廂情願的錯誤——就是神話。作者認為，「人多力量大」這樣的思想只存在於每個工作人員都是獨立的個體，他們之間沒有或幾乎沒有相互的交流的情況。而在程式設計中這是不可能的。作者舉了乙個十分形象的例子：母親懷胎十月可以生下小寶寶，但十個母親每人懷胎乙個月可以生下小寶寶嗎？這顯然是乙個偽命題。
我並沒有過大型開發的經驗，但從《人月神話》發行40年後依舊經久不衰，甚至被譽為軟體行業的「聖經」來看，作者的思想很顯然在實踐中得到了證實：人月神話是正確的：開發軟體並不是人越多越好。
其實還有一點我不得不說：作者說：「每個程式設計人員都是樂觀主義者」。這點我還是深有體會的：在每次程式丟擲異常後，我總是第一時間腦海中閃過這樣的話：怎麼可能錯（檢視異常）嗯？這裡怎麼會丟擲異常？我的程式沒有錯誤啊？一定是平台錯了！額……我還是再檢查一遍吧，畢竟真是平台的錯誤我也沒有辦法啊……然後，我就檢查出了我的程式錯誤……
閱讀筆記 人月神話02
人月神話 主要討論的便是人和月之間的關係。並且怎樣處理系統開發的預估，正如作者所說 在眾多軟體專案中，缺乏合理時間進度是造成專案滯後的最重要原因。首先，我們對估算技術缺乏有效的研究。過於樂觀 第二，我們採用的估算技術隱含的假設人和月可以互換，錯誤的將進度與工作量相互混淆 第三，由於對自己的估算缺乏信...
《人月神話》閱讀筆記02
在專案完成過程中，一定要準確書寫專案工作手冊，這便利於日後的管理和維護，若工作人員對硬體或軟體的某一部分存在疑問，通過檢視工作手冊，即可快速解決問題。在講到工程專案中的管理問題時，文中提到三點建議，第一，小型專案中產品負責人和技術主管最好是同一人 第二，產品負責人作為總指揮，技術主管充當左右手的管理...
人月神話閱讀筆記02
繼續人月神話的閱讀。在書中，作者提到了關於外科手術式的隊伍。這點是我剛開始稍微有點不理解的。我們都知道，在現代的開發中，一般不會有個人開發的情況，畢竟乙個人不會將事情做得那麼全面，無論他是多麼的強大，個人能力是多麼的突出，他仍然會在一些情況下出現各種各樣的問題，所以，我們一般的都是採用的多人參與開發...