上一次读是在学完《设计模式》之后不久，对模式的理解是：它是一种前人经验的积累，比如房子坐北朝南最初是为了接受更多的阳光，由于这是一个很好的经验，慢慢被广为接受，形成了模式。还有房顶的样式，飞檐是引导雨水的，成为模式后渐渐变为了一种审美上的东西。也就是说模式是一种前人应用经验的精炼，能够减少设计时候的弯路。

这次看又体味到了一种新的观点，模式为人广为接受以后，形成了一种共同的语言，它将一种模式的细节包含在一个短短的短语之中，人们都能理解这短语之后的各种细节。人们在交流的时候使用这种语言可以免去细节的阐述，而且能更明确的理解对方的意图。

应用在软件上首先是设计模式，它的命名包含了如何建立Class的细节，当人们都理解后，在描述设计的时候就不用再去阐述细节了。

另一种是软件使用者层面的，比如“windows式的开始菜单”、“HTML超链接式的命令列表”。可以非常直观的描述对操作界面的要求，而且比直接描述更准确，不容易引起误解。这种模式不一定是最优实践积累下来的，而是一种习惯的延续。由于用户习惯了一种操作风格，所以才会有这种要求。这个层面是我以前没有想到过的。在书中写道：“在有生气语言的城市中，模式语言如此广泛，以至每个人都可以使用它。”提到了模式语言非常简单所以每个人都可以理解，还提到了现代模式语言的瓦解，以至于最终使得设计工作变得非常专业，语言成为私有，所以无法沟通。同时人们又害怕自己犯愚蠢的错误而更加退缩。

我在很多项目里面都感觉很难和客户沟通，很多客户对我们的提议没有任何概念，无法判断好坏，同时又以怀疑的眼光看待这些提议，迟迟不敢下决定。一方面我们感到不被信任，心中愤愤不平。客户总觉得我们在回避困难，不愿意提供好的服务。这就是因为双方使用的共同语言太少，无法相互理解对方的意图。软件这一行范围很广，术语太专业太复杂，我们作为从业者都无法理解所有的术语更不要提客户了。需要一种简单的广泛的模式语言来弥合客户和系统分析人员的鸿沟。“windows式的开始菜单”、“HTML超链接式的命令列表”都是很好的模式，但是有的模式太微观，很难让客户对整体模式作出描述。所以作出的很多软件往往缺乏整体风格，显得很凌乱而且使用不便（每个部分都要重新学习使用方法，重新适应操作习惯）。更好的描述是“XXX类型的编辑器”，“XXX式的结果表示”，“使用XXX方式连接两个窗口”等等。

书中还提到了模式语言的包容性，就是各种模式是层层嵌套的。宏观上有一个区域的模式语言，然后再细一些是城市的模式、社区模式、邻里模式、建筑群模式、建筑和房间模式一直到构造细部模式。软件也是这样，有宏观的构架模式，用户界面总体风格模式，再细下去有模块划分模式、模块内部Class构造模式、界面操作模式，再往下有程序内部成员的模式，代码的模式。很难想象一个设计师能把这么复杂的一切全都安排的妥妥当当的。这么多的模式语言也是一个人不可能全会的。所以软件的分工非常重要。而且不能轻视任何地方。