骨灰級的經典書籍。1975年的作品，1995年再版，到如今再次讀來，依然還是受益匪淺。

講的是什麼？

《人月神話》是一本講軟件工程的書。書中幾乎探討了所有與之相關的內容。包括進度管理、團隊搭建、人員交流、文檔編寫等，不可謂不全面。而書中也有很多有意思的比喻，十分讓人喜歡。

有趣的比喻

我們先從比喻説起。書中用焦油坑，來類比大型項目裏，很多程序員的感受。渴望施展拳腳，卻只能在焦油坑裏掙扎。是不是很形象？而對於催進度方面，書中使用了廚子的比喻。就如做菜一樣，總是需要時間的，催的着急了，可以説快了，但最終上菜的時間，其實和一開始估算的，沒什麼區別。書中還有很多這種類比，每篇都有一兩個，有些還配了插圖，有興趣的話，都可以看看。

到底什麼是人月神話

好了，讓我們來解密什麼是人月神話。當然，不是講一個人和月亮的神話故事。人月其實是個評估工時的指標。比如，一個人幹一個月。那為什麼説是神話呢？這是因為，由於項目開發的複雜性，10人3月的開發週期，很難簡單地換算成30人1月。新人的加入，會增加很多培訓成本和溝通成本，而任務本身在次序上的約束，也導致了不能用簡單的方式分解。所以，通過人月直接換算工期，是個不存在的神話。當然，這個老先生認為解決不了的問題，讓聰明的中國人解決了。就是讓這10個人死命加班，凌晨也不睡覺，乾死拉倒。

概念完整性

書中感慨於蘭斯大講堂在整體完整性上的美感。幾百年建設的大教堂，前後經歷了八代建築師，他們犧牲了自己的一些創意，以獲得更純粹的整體設計上的完美。軟件工程與此類似，由於總是多人合作完成的，在概念完整性上，不統一的問題也尤為突出。軟件項目，本身的一個大目標，就是要讓系統變得更容易使用。而每個人的個性發揮，會讓系統變得極其混亂。事實也證明，現實中的很大一部分bug，特別是不容易被發現的部分，都是和開發人員間概念不一致有關。犧牲個人個性，換取整體的一致性美感，這才是一個優秀的程序員該有的信念。

組織構建

書中建議我們把設計工作和實現工作分開。這樣，設計工作由一個專業人士完成，能很好的保證概念完整性。我們常説的架構師，大致就是這種職位。書中還提供了外科手術式的團隊構建理念。一個優秀的人，帶一些相對普通的技術，配合他完成工作。現在很多公司的小組方式，本質上也應該是此種構成。書中也明確了組織的本質：“因為交流才出現的組織”，這個需要你細細品味。當然，設計和實現的分離，會讓有些人覺得沒有價值。書中的觀點是，設計工作和編碼實現的工作，其實都有很多不一樣的挑戰。

銀彈理論

“沒有銀彈”的論點，就是這本書的作者提出的。他在大約30年前，做了一個大膽的預測：在未來一段時間內，並沒有像有解決狼人的銀質子彈那樣，會出現一種單獨的技術進展，能讓軟件工程的生產率，有數量級的提高。這主要是因為，軟件工程的主要困難是設計，而實現只是其次要困難。我們不可避免地要面對軟件設計上的複雜度、一致性、可變性和不可見性。而這些並沒有看到，類似“銀彈”的技術出現。誠然，現今AI發展迅猛，作者也在1997年就談到了AI輔助編程。但目前來看，AI解決的還是次要問題，並沒有很強的能力，解決主要困難。當然，作者的觀點貌似有些悲觀。但當你閲讀過原文的話，可能會有不一樣的體驗。

寫在後面的話

書中多是作者做大型軟件項目的經驗之談。基礎量級都是5000人年的系統。而對於互聯網項目來説，很顯然太過重型了。不過軟件開發，大同小異。書中每一章節所討論的問題，都值得你去仔細思考；而每一章節的內容，也會對你有不小的啓發。