從設計模式開始，已經有很多人嘗試總結了各方個面的很多模式。不管是寫的人多，讀的人也多。甚至考的人也多。數年前去IBM面試實習生，Mentor問我的問題就是知道什么是Visitor模式不。但是模式為什么出現，這些牛人為什么花這么多時間精力去討論，去總結，我還是最近才開始有所領悟。

事情的起源是公司內部的一些討論。我們公司（ThoughtWorks）是做敏捷咨詢的。很多咨詢師都是非常有經驗的開發人員，但是做開發有經驗未必做咨詢有經驗。在國內做過幾個大的咨詢項目之后，不少同事都有一些咨詢方面的經驗收獲。個人都想做一些總結，以幫助咨詢經驗不多的后加入者。領導層也非常支持，覺得這個事情非常好。

我想很多人都有類似的“文檔化經驗”的想法吧。但是這種事情一旦落實到如何去做的時候，就爭議頗多。有人就建議，不如來一個工作手冊。把第一天做什么，第二天做什么都寫下來。此論一出立馬引來非常多的反對。反對的意見是非常有道理的，如果按照這樣的做法做下去，只會有兩個結果。要么，實踐者變得僵化，沒法給客戶提供他們真正要的價值。要么，按照手冊去做解決不了客戶的問題，客戶下次就不請我們了。總之，這種記錄“我們過去是怎么做”的東西都覺得沒什么用。大家最常提的一個說法就是，“每個地方的情況都不一樣”。

既然這種包含太多工作細節的工作手冊不行，那么我就來個Check List吧。把咨詢中能夠用到的工具都列出來。比如說，團隊訪談，比如說，復盤。這個說法呢，大家都覺得行。至少在研究問題的時候可以把Check List看看。這種做法其實是效仿XP。極限編程其實就是一個Check List，包含了各種有用的Best Practices。這種做法又很類似Pattern，包含了各種各樣的經典的應對之策。

所以模式是什么？模式就是一種“記錄經驗”的工具。無數前輩大拿覺得自己有經驗可以和整個行業共享，他們選擇的方式就是模式。但是，模式在實際的應用效果中是并不盡人意的。最主要的問題就是模式的誤用。而這種誤用的根源，我覺得就是他們的名字。模式本身的內涵是非常豐富的，完整的模式包括Context，Solution, Forces, Resulting Context。但是統領所有內容的標題卻只是Solution。這樣就容易讓人只記住Solution，而忘記了它所適用的場合。或者因為不是完全理解適用的場合，而在適合的場合錯過了應用模式的機會。

另外一個缺點是模式的整理不是按問題分類。經常我們會發現，對同一個問題，其實有好幾個適合的模式。比如，提供了一個擴展點，我們既可以用Template Method，也可以用Strategy。但是由于模式是按照解決方案分類的，這樣就沒法對問題進入深入的討論。而我們在應用模式的時候，首先面對的是手上的問題。從問題，到解決方案，這才是真正的經驗所在。而模式本來的意圖就是“記錄經驗”，卻把這經驗最重要的一部分沒整理好。并不能說模式沒有包含這一塊的內容，好的模式書都有對什么問題適合什么模式的深入討論。只是問題出在了整理方式上。

James Coplien經常強調一個Pattern Language。其實就是嘗試把Pattern按照其服務的Context組織成一個Language。有點把模式按照問題組織起來的意識。但是他歸納的Pattern Language都比較高層，比如說Organization Construction Pattern Language。但是我覺得對于具體問題更好。比如說，項目上要培養新人怎么辦？這個時候就可以去比較DayCare和PairProgramming這些組織模式在處理這個問題上的適用性。

所以我覺得很多模式，都應該按照所處理的問題做一個重新的整理。整理出來的結果就是一個“問題清單”。我覺得這比“模式清單”要有用的多。即便這個問題清單不去寫解決方案，光是深入地討論這些問題就非常的有價值。問題分為兩類，一種是錯誤，那么我們可以“有則改之，無則加勉”；另外一種是常見的挑戰，那么我們可以在真正遇到的時候敏銳地發覺我們已經有前人的經驗可以利用了。

雖然這似乎只是認識上一小步進步。但是讓我卻非常激動：）最近對組織模式非常感興趣。下一篇就從問題入手，嘗試把組織模式給重新整理一下。Oh了。