拜讀完brooks的《設計原本》后頗有感觸。這個天才設計師用簡單的200多頁紙濃縮了軟件設計中的種種問題，并給出了行之有效的建議，可謂是精彩絕倫。讀完以后有茅塞頓開之感，要點總結如下：
1、設計需要過程模型來指導設計進程，現在看到最符合實際的過程模型是Boehm的螺旋模型，但brooks認為還有很大改進空間。
2、需求永遠和合同有密切關系，而需求的變化又和合同本身發生了割裂。brooks建議了一種合同模型，這種模型將設計和實現分成兩個合同分別簽署。
3、無論是本地協作還是遠程協作，最重要也是最需要解決的問題是各團隊對架構本身的一致理解，即架構的概念完整性。brooks堅信面對面交流是最好的協作方式，無論用什么高級工具（郵件、即時通信等）效果都很差，除非雙方已經合作多年，才不會出現偏差。
4、brooks認為軟件設計，不僅需要理性主義，即充分的思考和理論的推導，更要證實主義，即要將設計盡快轉化為可用原型來證實設計的正確性。（我在這幾年也幾乎被變成了一個證實主義者，呵呵）
5、千萬不要去猜測用戶的行為，因為設計師不是用戶，一定要與客戶交流，確保清楚用戶的真正行為，而不是靠經驗去假設和猜測。
6、要準確識別什么是核心資源？內存？CPU TICK？每個部件只能耗多少瓦？這些資源需要嚴格控制，確保系統的高效。
7、約束，是明確設計的朋友，像是畫家需要知道畫布大小。室內設計師需要知道房間大小一樣。明確的約束可以帶來更好的設計，到需要注意的是約束會隨著時間變化，比如，內存已經不再是一個重要的約束。
8、設計中的美學，與風格相關，看看iphone和ios系統的設計就清楚了。
9、過去的成功的方法，現在不一定也成功，brooks認為這來自于設計師的自負。并舉例說明了JCL語言在以往系統中的成功，但在System360系統中的徹底失敗。
10、在大規模系統，專業學習時間長，分工更細的情況下，需求、設計、實現的分離，導致實現與設計不一致的問題非常突出，為了解決該問題，brooks提出了4種補救辦法。這各種辦法總結在我的（需求，設計，實現分離的問題——源自《設計原本》）中有總結。
11、設計決策，變更需要有明確的記錄或日志，這是為了設計師從歷史學習更多東西，避免無知的低級錯誤。而這個記錄幾乎不能很好的被保存，市面上有很多工具，都很有誘惑力，但公開的工具大都效果不好。
12、偉大的設計來自于偉大的設計師，而非偉大的設計過程。
13、繁雜的過程和瑣碎的管理工作只能培養出優秀的設計師，而非偉大的設計師。要有意識的培養他們，甚至于書本知識也不算浪費。防止他們分心，并在不斷的設計草圖上，批判、修改、再批判、再修改中成長。
14、無論是設計階段還是實現階段，仔細的檢查核實非常重要，就算是頂尖的設計師也會犯錯誤。
15、設計中一定要考慮后期如何維護，因為在交付使用后會經常維護。
16、brooks堅信在設計上多花時間不會提高這幾個產品的成本。
17、與用戶大量交談，向他們現實原型，再次檢查各人員工作，確保這些理解是正確的。
18、將設計工作量投入到更重要的地方，比如，廚房和起居室呆的時間更多，那么就需要投入更多時間去設計這兩個地方。
19、仿真環境與仿真模型比起來效果更加突出，在虛擬環境上執行大量用例，會更好的驗證設計。
20、市場預測在已有產品上才有效，對于新產品，設計師應今早讓市場人員理解新產品的概念。
21、聯合設計的問題。何方利益的界定能組成組織結構的快速達成共識。需要制定一個仲裁方案保障各方利益。設立各方各團體代表，保障各方利益。定期組織會議解決各方沖突。會議議題必須在下面評審通過再上會，避免無效會議。
