如果你是非常有經驗的朋友，如果你很少或沒有設計和編碼效率低的問題，請略過本文。
開門見山：
一、初學者如果第一次聽說模式，可以擁有一本GoF的《設計模式--可複用面向對象軟件的基礎》，不學，放在手邊當字典。
二、模式的學習，以實際問題爲出發點，初學者熟悉最常見的兩三種模式，對模式有直觀認識即可。有經驗的建議你用什麼模式的時候，去查“字典”即可。
三、有一定積累之後，想學習了，如果GoF的看不深刻，又想系統學習，建議看《Head First設計模式》。
四、對於架構模式之類的，可以在工作中有系統設計開發的經驗或者相關的基礎以後，系統的“總結”學習，避免以偏概全。此時推薦幾本書《敏捷軟件開發——原則、模式與實踐》，《企業應用架構模式》，《J2EE核心模式》（JEE領域的話），《面向模式的系統體系結構》（共5卷，建議選擇性）。
如果你有興趣，或者對上不認同，不妨往下讀讀，交流一下吧。
本文有點挑刺的感覺，所以想了很久纔敢寫下來，希望拋磚引玉。我喜歡通俗的闡述問題，所以，對於“是”這樣的判斷句，請諒解，我沒有定義或裝權威談標準的意思，我是想對於特定的觀點，以簡單易懂的方式來說明。
設計模式、系統架構模式、企業應用架構模式、J2EE核心模式……，我們有很多專家、前輩和敬業研究者總結了很多的經驗供大家學習交流，同時我們也許也總結了自己的經驗，分享與他人。然而，很多人言必模式，設計的時候照着模式硬搬死套，coding的時候拿書對照。。。，有時候不得不佩服，畢竟他很專注，很認真，可從實際的角度，總讓人覺得有點悲哀，怎麼都有點以前抄八股文的感覺。
其實對於團隊或者聽來的其他公司的這些現象，我早想和這些朋友一起探討下。
模式很好。因爲它爲一定環境下的場景提供了經過驗證的成功的方案，運用模式，可以讓我們少走彎路，提高效率。而且，模式也是大家解決問題時候進行交流、達成共識的共享知識庫。
可是我爲什麼說那些抱着書本說模式的方法不好呢，原因很簡單：沒有了解模式來源以及相比其他方式的優勢，是很難深刻理解模式的。所以我們經常看到模式的濫用、誤用。
當然這樣也許偏頗了，也許你就是例外，你有了一定經驗，能夠慢慢/或者很快就理解模式的深層次的東西，那你值得佩服。但是，我所知的一些朋友，如果沒有經驗的，對模式的瞭解大多是形式上的東西，導致使用起來，生搬硬套，效率地下，或者根本牛頭馬嘴，讓人啼笑皆非，當然，我沒有嘲笑的意思，我希望他們能理解我們的好心。
當然，對模式的推崇，尤其是對設計模式的過分推崇，導致很多人盲目的背誦、記憶，像背英文單詞一樣。這也許是行業的悲哀吧。
不才這裏想和這些朋友討論一下關於模式學習和使用的問題。當然我先拋磚，期待引來你玉了。
一、沒有寫過多少代碼，也沒進行太多詳細設計的人，上來就係統的設計模式學習的方式，比如直接把GoF的《設計模式》拿來背誦的，勿取。本來設計模式是經驗總結，幾乎沒有基礎經驗的，對不良設計沒有概念，動輒用模式，常常將模式用成了不良設計。這種情況太多了，所以這裏列出來。一方面，建議積累一點經驗，或者從設計/編碼結果上學習，一定積累後，再系統學習設計模式，效果也許要好得多。
現在流行的敏捷方法，其實對於模式的要求更高，而且，敏捷的很多方法對學習設計模式確是有益的，比如儘快建立可用的系統，然後需要的時候再進行重構，實際上對於有些朋友來說，就是不要求你寫最好的代碼，你就先寫出來，覺得以前的代碼不能解決問題了，就重構，這時候經過檢驗的優秀的模式也許就派上用場了。這樣一個過程，定要比背八股文有意義的多吧。
對於這一點：推薦一本書：Robert.C.Martin的《敏捷軟件開發——原則、模式與實踐》，不是關於敏捷的方法、指導，而是設計的原則、模式，很好的一本書。
二、學模式，先學面向對象方法。設計模式的基礎其實就是面向對象設計的原則，模式是在原則的基礎上，對實際使用場景的歸納總結（不是定義和權威，是一種理解，請容許不準確）。面向對象的設計原則如SRP單一權限準則，OCP開閉準則等，網上搜搜吧，其實是很好的思想。
三、關於架構模式，建議有較多經驗的朋友再去學習吧。推薦Martin Flower的《企業應用架構模式》。另外有一系列：《面向模式的軟件架構》也許可以一睹。
四、具體領域：Java EE。我以前讀《J2EE核心模式》的時候，感覺不深，後來SSH（Struts+Spring+Hibernat）用過之後，再回去，看該書的內容就經常拍案叫絕。還是建議有點實際經驗，再系統學習吧（如果你已經知道這種方法不適合，請用自己的方法）。