经过前面的一番解说。相信你已经对系统重构有了一些初步的认识了。
一切的一切仿佛在告诉我们，系统重构总是与需求变更无关。
但此时，我不得不告诉你这是真实的谎言。
我们的软件系统总是处于一种变化之中。而且往往是一种由浅入深、由易到难的过程。
可是，当系统复杂程度发生变化时，我们应当及时调整我们的设计。来适应新的变化。
然而我们没有做到这一点，所以我们的系统维护变得越来越困难。要解决我们的问题必须通过系统重构去优化我们的程序，使之又一次适应业务需求。
毫无疑问，需求变更才是我们去重构的主要动因。
然而。系统重构要求我们不能改变软件的外部行为，这意味着在重构的过程中不能为软件加入不论什么新功能。重构仿佛与变更无关。这就有些让人搞不懂了。我们由于变更才尝试重构。但重构却不让我们去变更！
破解这个真实的谎言的关键就是。系统重构并非禁止我们变更，而是应当以“两顶帽子”的方式进行变更。
什么是“两顶帽子”呢？就是当我们须要变更系统时。应该将变更的过程分为两个步骤：首先是不加入不论什么功能先重构我们的系统，使之适应新的需求；然后開始变更，实现新的需求。第一步正是我们所说的重构，它既要保证原有功能的正确无误。又要使系统结构可以适应新的需求。为了达到这个目标。我们让重构必须在不改变软件外部行为的前提下进行，调整的不过其内部结构，外部功能保持不变。当软件的内部结构可以适应新的需求时，我们才開始加入新的功能，顺理成章地实现新的需求。
你可能会问，为什么要搞那么复杂呢？让我们先剖析一番以往我们是怎么加入新功能的。
当用户来了一个新需求时，我们改动代码的首要原则，是对新需求的改动不能影响以往的功能。我们过去怎样做到这一点的呢？事实上我们没有什么好的办法。一个直观的想法就是，原有代码改得越少。改动量越小，改动出错的风险就会最小。正由于如此，即使原程序已经不适应新的需求。但程序猿也不愿去改动程序的结构。而是就着现有代码不断地往里加入程序。随着时间的流逝，加入的程序越来越多、越来越乱，因而系统维护成本越来越高。
採用系统重构全然就不是这样一个概念了。这里当原程序不适应新的需求时。我们採用的策略是一种“糟糕设计零容忍度”的策略，即先重构系统使之首先适应新的需求，再顺利成章去实现这些需求。
因为“不改变软件外部行为”，我们能够非常easy地建立測试机制，在測试机制的不断监督下，有质量地保证重构的成功。然后我们再实现新功能时，能够保证易于实现。而且使得可读性、可维护性和易变更性得以保障。这种过程避免了那些因变更而带来的糟糕设计。从而避免软件质量的下滑。所以，理解“两顶帽子”、习惯“两顶帽子”，对于学习和使用系统重构，显得尤为重要。
大话重构连载首页：http://blog.csdn.net/mooodo/article/details/32083021
特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重。谢谢！