作为程序员，我们收集，组织，维护和利用知识。我们用文档把知识融于规格说明当中，
使它在运行的程序中活跃起来，在测试中用它来提供所需的检验。

不幸的是，知识不是恒定的。它总在变化——常常是骤然的。随着一次和用户的会谈，你
对于一条需求的理解就变了。政府改变了一条规章制度，某商业逻辑随之就过时了。测试
可能表明所选择的算法不敷实用。所有这些不稳定性意味着，我们的时间大部分化在了维
护工作，以及重新组织和重新表达系统中的知识上。

大多数人想当然地认为维护始于应用程序发布之时，那种维护意味着除错和增强功能。我
们认为这些人错了。程序员总是不停地在维护。我们的理解日复一新；我们还在设计或者
编程的时候新的需求就到了；可能环境总是处于变化之中；不管是何种缘由，维护不是一
种断续的活动，而是整个开发过程中的每日例行公事。

在我们执行维护的时候，我们得找到和改变事物的表达——那些包含于系统中的知识汇聚
块。问题在于实在太容易在我们开发的规范，过程和程序中复制知识了，而且一旦我们这
样做，我们就引入了管理梦魇——这梦魇早在应用发布产品之前很久就开始了。

我们觉得，可靠地开发软件，以及使我们的开发更易于理解和维护的唯一方式，就是遵循
我们称之为DRY的法则：

在一个系统里每一条知识都必须有一个单一的，无二义的，权威的表达。

为什么我们要称之为DRY呢？

诀窍 11：Don’t Repeat Yourself. (不要重复你自己。)

反之就是在两个或两个以上的地方表达同一事物。如果你改变一处，你就得记得去更改其
它，否则，就像那个外星计算机一样，你的程序将由于自相矛盾而崩溃。你是否能记得不
会是一个问题，问题在于何时你会忘记。

贯穿全书你将发现DRY法则会时不时出现，甚至会出现在和编程无关的上下文中。我们觉得
这是实用程序员工具箱中最重要的工具之一。

在本节中我们将略述重复之难题，并提出一些应付的一般策略。