经过前面的一番讲解，相信你已经对系统重构有了一些初步的认识了。一切的一切仿佛在告诉我们，系统重构总是与需求变更无关。但此时，我不得不告诉你这是真实的谎言。

我们的软件系统总是处于一种变化之中，并且往往是一种由浅入深、由易到难的过程。但是，当系统复杂程度发生变化时，我们应当及时调整我们的设计，来适应新的变化。然而我们没有做到这一点，所以我们的系统维护变得越来越困难。要解决我们的问题必须通过系统重构去优化我们的程序，使之重新适应业务需求。毫无疑问，需求变更才是我们去重构的主要动因。

然而，系统重构要求我们不能改变软件的外部行为，这意味着在重构的过程中不能为软件添加任何新功能，重构仿佛与变更无关。这就有些让人搞不懂了，我们因为变更才尝试重构，但重构却不让我们去变更！破解这个真实的谎言的关键就是，系统重构并不是禁止我们变更，而是应当以“两顶帽子”的方式进行变更。

什么是“两顶帽子”呢？就是当我们需要变更系统时，应该将变更的过程分为两个步骤：首先是不添加任何功能先重构我们的系统，使之适应新的需求；然后开始变更，实现新的需求。第一步正是我们所说的重构，它既要保证原有功能的正确无误，又要使系统结构能够适应新的需求。为了达到这个目标，我们让重构必须在不改变软件外部行为的前提下进行，调整的仅仅是其内部结构，外部功能保持不变。当软件的内部结构可以适应新的需求时，我们才开始添加新的功能，顺理成章地实现新的需求。

你可能会问，为什么要搞那么复杂呢？让我们先剖析一番以往我们是怎么添加新功能的。当用户来了一个新需求时，我们修改代码的首要原则，是对新需求的修改不能影响以往的功能。我们过去如何做到这一点的呢？其实我们没有什么好的办法，一个直观的想法就是，原有代码改得越少，改动量越小，修改出错的风险就会最小。正因为如此，即使原程序已经不适应新的需求，但程序员也不愿去修改程序的结构，而是就着现有代码不断地往里添加程序。随着时间的流逝，添加的程序越来越多、越来越乱，因而系统维护成本越来越高。

采用系统重构完全就不是这样一个概念了。这里当原程序不适应新的需求时，我们采用的策略是一种“糟糕设计零容忍度”的策略，即先重构系统使之首先适应新的需求，再顺利成章去实现这些需求。由于“不改变软件外部行为”，我们可以很容易地建立测试机制，在测试机制的不断监督下，有质量地保证重构的成功。然后我们再实现新功能时，可以保证易于实现，并且使得可读性、可维护性和易变更性得以保障。这样的过程避免了那些因变更而带来的糟糕设计，从而避免软件质量的下滑。所以，理解“两顶帽子”、习惯“两顶帽子”，对于学习和使用系统重构，显得尤为重要。

大话重构连载首页：http://blog.csdn.net/mooodo/article/details/32083021

特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！

大话重构连载6：一个真实的谎言