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