全部學習彙總： GitHub - GreyZhang/The_Mythical_Man_Month: My reading notes of The Mythical Man-Month.
如同我在這一章的封面上标注的，我把整體部分改成了整體與部分用到了我這一份筆記的标題。因為整體部分可能會讓人隻會想到整體而忘記了部分，然而這不是書的本意。這本書的翻譯，充斥了大量的類似問題，我估計可能會是老師帶着幾個學生翻譯出來的。這本不是什麼問題，但是校對又可能沒有做到那麼多的檢查，也就出現了這樣的局面了。
這裡面有一個針對誇誇其談的人的答複，我覺得很讓人覺得透氣。其實，我覺得現在流行的linus的評價也可以用來作為一個替代的回答：說都可以說，給我看看你的代碼！
子產品之間的互動可能會是bug的重災區，而這種現象在于子產品化設計以及分工合作的團隊中肯定是如此。而減少這樣問題發生的有效手段就是減少模糊性。
這裡提出來了一個模式化的開發流程，其實在現在的軟體開發行業中依然是奏效的。然而，這樣的流程化的開發模式可能不見得在所有的團隊中都适用。尤其是，很多團隊的項目管理人員對此認識不夠，而結構師又沒有足夠多的經驗，就很可能隻是放一個架構的說法在這裡，實質上還是工程師信馬由缰。
減少bug發生的有效手段，其實可以做一個精簡的總結：1，架構設計明晰； 2，功能描述明确（需求） 3，細節屬性到位 4，測試提前。
設計不能夠總是看細節，也要有一定的大局觀。
做什麼之前先進性充分的思考，其實我覺得這個即使是現在計算機資源充足的條件下也是适用的。過去的多年的工作中，我從一些老牌程式員的故事中學到了這一點而且在我自己的實踐中貫徹執行。而這些，都成了我成長的法寶。
曾經，軟體調試是一個成本特别高的過程。而現在，雖然我們手頭的資源有時候還是看似不足，但是已經好了太多。别的不說，看看曾經的電腦裝置，16K的存儲都得糾結，而我們現在單片機也都有超過這樣資源的存儲。
之前軟體調試比較麻煩，很大的一個局面是一群人守着一台電腦裝置，而這個電腦裝置不支援分時複用，興許也就不支援多使用者同時使用。打破這個局面的方式可能是後來的unix的問世吧？
這裡給出來了兩種方法，其實，我覺得沒有絕對的優劣。就我個人的了解來說，獨立的開發人員開發一個項目，前面的方法好。而合作開發的時候，後面的方法好一些。
這種方法我自己感覺用不起來，但是這個是KEN老爺子的成名絕技。我嘗試過做類似的調試，但是幾次嘗試都是失敗的，還是沒有擷取到其中的精髓要點。
項目管理得感謝現在出現的一些優秀工具，其中就包括版本管理工具。其實，同時需要感謝這些工具的還有軟體工程師，這些工具給軟體工程師提供了時光機，有了可以後悔的機會。