习惯一：让时间来反映(reflect)。
在模式写作中的最重要的活动就是反映(reflection)。Bruce Anderson
,最早对我们的工作有影响的人，曾经很多年强调这一点圣谕(mantra)。
让时间来阶段性的反映你所做的东东。想想你所做的系统，你所遇到
的问题，和你是怎么解决（或没解决）它们的。
这些阻碍是在日益变短的开发时代中的所有而且是不可想象的。不过
反映是紧迫的。有比无头脑的去hack更好的进入创造性轨道的方法。
你可能产出大量的工作代码，不过代码量是一个不好的工作量的衡量
手段。好的设计的标志实际上恰恰相反---它是量小并且优美。用少量
代码完成大量工作。它实现所有的东东"once and noly once"，就像
Kent Beck喜欢说的。它也很灵活，大体积的代码通常不是这样的。
现在，希望人们每年拿出一个月去构想是不实际的。不过你能做的是
增量的记录你的经验。当你有重要的问题需要解决时，尝试着马上
把它写下来。迅速写下描述问题和为什么它困难的笔记。然后，开始
对它的工作。任何时候你尝试一个新方法时，迅速写下它。如果这个
方法失败了，也迅速写下它，并且写上为什么它失败了。如果它成功
了，也照做。几乎所有人都能用5%的时间写下他们的经验---这也可以
作为纪律。
如果你仔细做了这些，你将会惊讶你所积累的写下来的经验。这是模式
的最原始的素材。当然仍然会有很多需要做的，不过你得到了所有重要
的可以提炼金子的智慧的矿石。
另一个重要的活动是尽你所能多看别人所设计的其它的系统。最好的从
其它系统学习的方法是去实际构建它们。如果你们没有时间或金钱去那样
做，至少读一下它们。寻找对它们所代表的的问题和怎么表示的理解。
学习细则(specifications)和文档。读研究系统的论文。浏览OOPSLA和
ECOOP进程(proceedings)。软件实践和经验是另一个好的设计和实现的
信息来源。
当你测试一个系统，尽你所能努力搜寻所有的东东。试着找出你已经知道
的模式。评估解决方案怎么从出版了的那些模式中变化。注意新的设计
方案，它们可能代表新的模式。不过记住相关的很少的设计方案是真正的
新的。更通常，人们使用已知方案的变体。一个新的和独一无二的解决方
案可能不够广泛可用而成为模式的形式。
如果你发现看上去新的东东，在你试着把它写成模式之前确定它在其它的
上下文(context)中也可以用。我们开发<<设计模式>>时有一个重要的规则
:我们在为一个问题写模式之前，必须找到它的两个存在的例子和它的解决
方案。这是我们所遵守的特别重要的规则，因为我们在探索不熟悉的领域，
并且我们想要确定我们所写的现实中也存在。我们不希望做一个没有任何人
有的问题的解决方案。终极的，我们抛弃了许多有吸引力的并且潜在有用的
不过没有在实际应用中看到的模式。

习惯二：坚持(adhering to)一个结构
一旦你有了原始素材，你怎么把它们写成模式的形式(form)呢？
好，首先，不要假设只有一种模式的形式。没有一种形式适合于所有人
。一些人喜欢像Alexander那样更通用(prosey)的风格。另一些喜欢像
<<设计模式>>中使用的更细粒度(fine-grained)方法。还有一些使用
完全不同的结构。这些结构所共享的特性只是它们的结构。
如果有一个大多数人同意的著名的术语，它将是亚历山大定义(Alexandrian
canon):一个模式是“对特定问题在特定环境的特定解决方案”(a solution
to a problem in a context)。现在我很大胆的稍微修改一下这个定义:
一个模式是对特定问题在特定环境的特定解决方案的结构化的清楚的
明细的解释(structured exposition)。模式有可识别(recognizable)的部分,
这些部分引导它们的应用和比较。这些部分包括一个名字，一个问题的陈述，
环境和解决方案的修正，和解决方案本身。这基本上是Alexander模式的结构
。我们的模式更进一步把这些基本要素分解成更集中的处理，如“适用性”，
“参与者”，和“效果”小节。1994年的模式语言编程(PLoP)进程会议包括
令人惊讶的对这些主题的不同的变化。
因此，把模式写在纸上的第一步是决定它的结构。你的模式的平均的信息量越多
，你的结构就越重要。一致的结构使模式具有统一性(uniformity)，使人们
更容易比较它们。结构也帮助人们搜索信息。更少的结构意味着更通用(prose),
可能会更适合于休闲的阅读，不过可能不为比较和参考目的所接受。
一旦你确定一个结构，确定你将始终如一的遵守它。你不必害怕改变结构，
不过你必须在每个模式中改变它，而且当你的模式成熟后这将变得更加
代价高昂。

习惯三：开始时做得更具体(Being Concrete Early)

在我们的模式中，“意图”部分表现得更直接明了(up-front)。
这是因为人们对先提出具体的术语，然后才是抽象术语理解得
更好一些。“意图”部分的具体例子给读者一个问题的参考和
解决方案的框架。这个部分演示的另一个方面是为什么其它对
这个问题的解决方法失败了，同样用具体的术语。把“意图”
部分作为一个介绍，读者能更好的理解(appreciate)通用的解决
方案。

具体化的直接结果是需要从真实世界中来的大量例子。例子
不应该是“意图”部分所独有的财产。在整个模式中使用例
子和反例(counterexample)描绘了关键点。即使是我们模板
中最抽象的部分(如“适用性”，“结构”，“参与者”，和
“协作”)有时也有例子。举个例子，有些“协作”部分包括
表示对象在运行时怎样通信的交互图(interaction diagrams)。
在讨论模式的抽象部分参考这些例子－－－即是在你抽象时
也要具体点。

另一个直接结果可能是术语：“告诉别人整个真实情况”
(telling the whole truth)。这意味着你必须提醒你的
读者这个模式的潜在的缺点(pitfalls)。很容易对优点
部分喋喋不休；不容易理解它们的缺点并且真诚的谈论
这些缺点。没有一个模式是完全没有缺点的，或额外的
开销，或在特定环境下的不良表现的，等等。确保你的
读者懂得这个模式会有缺点(fall short)。

习惯四：保持模式独一无二和优点突出
(Keeping Patterns Distinct and Complementary)

当你开发多个模式时有一个趋向需要避免。
当你写一个模式时，可能趋向于在细节和
口径(scope)同时增长。在这时很容易忘记
其它模式。模式之间的区别结果变得模糊了，
使别人无法分组(collectively)理解模式。
它们开始在口径和目的上互相重叠。这可能
对作者来说非常清楚，而对新手来说不那么
清楚。他们将不知道什么时候去使用一个模
式而不是另一个，因为它们之间的区别不那么
明显。

所以确保你的模式是正交的(orthogonal)并且
它们合力(synergistically)工作。持续问你
自己：“模式X和模式Y的区别是什么？”如果
解决相同的或相似的问题，你可以把它们合并。
如果两个模式使用相似的类层次(hierarchies)，
则不用担心。在OO编程中有这么多方法使用
相对少的继承机制。通常相同的类使用将会
导致表示广泛变化的明显的不同对象结构。
让模式的意图作为它们不同点，而不是实现它们
的类结构的指南。

一个测试你的模式怎样正交和合作的好的方法
是保持分离的文档来比较(compare)和对比
(contrast)你的模式。在<<设计模式>>中
我们提供了多个为了这个目的的部分。试图
在写下来的形式下解释模式关系的简单行为
给我们对我们的模式的新的视角。不止一次
它让我们重新思考它们的一些部分。

我的唯一遗憾是我们在游戏中没有早一点重视
关系。我建议你尽早开始写下这个附件材料。
这可能看上去是做傻事，特别当你有很多模式
需要比较。不过当你只有两个模式时，重叠
得可能性出现了。初期花时间比较和对比
泥的模式将帮助你保持你的模式独一无二
而且优点突出。

习惯五：有效的表达。(Presenting Effectively)

你的模式的质量取决于你表达它们好不好。你可能
发现世界上最好的模式，但它将不会帮助任何人除非
你有效的表达它们。

用“表达“(presenting)这个词我表示两件事:打印
设置(typesetting)和写作风格。好的打印设置是
页面设置(page layout),预览打印(typography),
图象(graphics)的技巧的事，而不管打印机质量。
使用你能得到的最好的软件工具(文字处理，画图
编辑器，等等)。用正规的(liberal)画图使用表达
你的关键点。你可能不会想到需要任何画图，但
只要有机会就那么做。至少它们去处枯燥，最好的情
况下它们能使你得到无论多少文字解释都无法得到
的表现效果。不必所有的画图都要有正式的类图
和对象图。非正式的画图，甚至草图常常能表达
相同和甚至更多的信息。如果你被“艺术性的被
挑战”(artistically challenged)了,那么让
别人为你画这个图。

好的写作风格比好的打印设置更重要。清楚的和
真实的(unpretentiously)写作。喜欢脚踏实地
的(down-to-earth)风格,而不是陈旧(stuffy)
和学术(academic)的风格。人们理解和喜欢
(appreciate)一个对话性的腔调，这个腔调
让它们对材料更容易被接受(receptive)。
在大多数作品中清楚明了和易于阅读是很重要的，
不过它们在模式写作中特别的重要。模式概念
太新并且主题问题太复杂，以至于有些人
很难弄懂它的所有要点。所有让模式友好
(approachable)的工作都应该做。

最好的学习怎么用对话式的方式写作的方法
是试着去做。确保你所写的所有东东是
你能听到你自己对朋友所说的。避免用
被动的腔调(passive voice)。打破长句子
和段落。使用日常用语，不要害怕使用
缩略语(contractions)。综上所述，让它
听上去自然些。

另一件每个人在生活的同一点要做的是读
一本或两本关于“写作风格”的书。有很多
可供选择的。我最喜欢的3本是Strunk和
White的<<The Elements of Style(whose
organization,remarkbly,is not unlike
a series of patterns)>>,Joseph M
Williams的<<Style:Ten Lessons in Clarity
and grace>>和John R. Trimble的<<Writing
with Style:Conversations on the Art of
Writing>>。像这些一样的书有为了好的，清楚
的写作的技巧。它们能帮助你不管模式的技术内
容而改进你的模式。

习惯六：无拘束的迭代(Iterating Tirelessly)

你不能在第一次就得到一个模式。你甚至不可能
在最初10次就得到正确的模式。实际上，你可能
永远不会得到完全正确的模式。模式写作是一个
永远不会停止(on-going)的过程。这个领域是新
的事实不会使事情好转。不过即使它不是.....
甚至有很多模式的好的例子和书帮助你写它们，
模式开发(像任何其他种类的开发)将是一个迭代
的过程。

期望写和重写你的模式很多次。不要指望一个模式
的完美，当你开始写下一个。记住，模式不是单独
存在的；它们互相影响。一个模式的一个重要的改
变将会很明显的影响其它的模式。用任何迭代，你
的努力应该殊途同归(converge)于同一点，不过
那正是模式稳定到让其他人阅读，理解和注释的
那一点。

习惯七：收集和采纳反馈(Collecting and
Incorporating Feedback)

Cervantes是对的：“对布丁的验证就是在吃它的
过程中”(The Proof of Pudding is in the
eating)。对一个模式的测试来自于对它的实际
应用。实际上，没有一个模式能被信任，直到
除了它的作者外的其他人使用了它。模式有潜藏
危机的特性(insidious property):它们通常被
熟悉牵扯到的问题和它的解决方案的人所完美的
理解。这些人以前不小心用到过这个模式。因此，
当他们看见这个模式时，他们能马上懂得它，
甚至如果模式并没有被很好的表达。真正的挑战
是让那些从来没有遇到这个问题的人也能理解
这个模式。没有不去从这些人得到和采纳反馈
而让他们懂得的方法。

鼓励你的同事用你的模式术语讨论设计。(让
作者也参与这样的讨论也可以。)在你的日常
工作中寻找使用你的模式的机会。试着尽你
可能的广泛的传播你的模式。你甚至可以
把它们提交到会议如PLoP或出版物如C++
Report,Smalltalk Report和Journal of
Object-Oriented Programming。这些传播
将会最大化你的模式的使用。

一旦反馈开始回来，准备听到最坏的消息。
我不记得多少次我被我所认为完全完美的的东东
彻底激怒了别人的事实所惊呆了的。否定的
反馈会让人失去信心，特别是在最开始
你最易受伤害和最想得到反馈时。虽然，
有些批评可能不正确或可能只是源于一个
简单的误解，大多数的反馈可能是正确地。
给你的审阅者怀疑的好处。做得很有帮助性
让他们快乐。你可能在长期中让许多，许多
人快乐。

No Silver Bullet

当然采用这些习惯不会保证你成为一个成功的
模式作家。而且上面所列的也不完整。不过至少
它能帮助你有成效的集中你的努力。你的模式越好，
它们的影响就越大。

然而，不是说所有人都要成为模式作家。
模式写作包括一个不小的投资，而且
不是所有人都能正确表达它。所有人
应该尝试模式写作一次，因为你不能知道
你是否擅长于模式写作。当时间流逝，然而，
我希望模式作家的数目被模式用户的数目缩减
－－－很像编程语言的用户降低了语言创造
者的阶层。