Joshua Kerievsky著, 译

部分摘录.

1.模式和极端编程（XP）都为软件设计、开发者提供了无法用金钱衡量的帮助。但是迄今为止XP大量关注于重构（refactoring），而对模式只字不提。在这篇文章中，我问''为什么''，并且最终描述出模式怎样以XP的方式更好地实现、以及XP怎样因为包含对模式的使用而变得更好.

2.仍在所知不多的时候我们就开始了自己的程序设计生涯，生产出的软件也反映出了我们的缺乏经验：我们创建的代码臃肿、错误百出、脆弱、难以维护、难以扩展。随着时间的流逝，我们成为了更好的软件设计者：我们从技术作家、专家那里学习，我们从自己的错误中学习。现在我们编写具有高度灵活性的软件，它适应广泛而且坚固。当被请求编写一个新的系统时，我们知道查明当前和将来的需求，这样我们可以设计软件来处理当前和将来的需要。

在软件开发生涯的这个阶段，极端编程告诉我们，我们经常对软件过分设计（over-engineer）了。我们从自己的错误中学到了太多，我们不希望重复这些错误，所以我们在系统生命周期的早期做了大量的努力来创造灵活而坚固的设计。不幸的是，我们没有认识到：如果这个系统永远不需要这个程度的灵活性和坚固性，那么我们所有的工作就都没有意义了。我们过分设计了。

我也曾经过分设计过。说实话，与其他设计者坐在一间房间里考虑如何设计软件来适应许多当前和将来的需求，这的确是一种乐趣。我们把自己学到的所有东西 --- --- 尤其是那些最好的经验 --- --- 应用在设计中。我们常常知道需求的列表会改变，但用户或客户总是改变需求。不过，我们认为我们可以足够聪明地设计软件，使软件足够灵活，使它能应付所有的需求变化。

典型的过分设计。

今天，极端编程将告诉你这是多么愚蠢的做法。XP说，我们必须让设计自己显现出来，而不是去预测设计将是什么样子。XP说，''做可能起作用的最简单的事''，因为''你将不再需要它''。另外，Kent Beck说：

你需要在一个强调沟通、简单、反馈和勇气的价值系统中选择最好的工作方法，这样你才能勇敢的脱离过分设计。[Beck1 00]

3.模式的实现有简单的也有复杂的。诀窍是：发现模式针对的问题，将这个问题与你当前的问题进行比较，然后将这个模式最简单的实现（解决方案）与你的问题进行比较。当你这样做时，你就不会在可以使用小规模解决方案的时候使用大规模解决方案。你获得了解决问题最好的平衡。

4.这就是我们需要的观点：重构的目标。这就是重构和模式之间的桥梁。它完美的描述了我自己在如何使用模式方面的进步：从简单开始，考虑模式但将它们保持在次要地位，小规模重构，只有在真正需要模式的时候才把重构转移为模式

5.当程序员需要做出设计决策时，很重要的一件事就是：他们应该试图保持设计简单，因为简单的设计通常比庞大而复杂的设计更容易维护和扩展。我们已经知道，重构意味着将我们保持在简单的路上：它鼓励我们以小而简单步骤逐渐改进我们的设计，并避免过分设计。