学习模式，不如先了解问题

从设计模式开始，已经有很多人尝试总结了各方个面的很多模式。不管是写的人多，读的人也多。甚至考的人也多。数年前去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了。