只要你的代码还有生命力，一定会有新的需求进来。而新的需求常常是你在编写这段代码之初始料未及的。
错误做法：
顺着既有的代码结构继续写下去，这里添一个if，哪里加一个else，长此以往，代码便随着时间腐坏了
如果用一个物理学术语描述这种现象，那就是“熵增”，这也就是大名鼎鼎的热力学第二定律。如果没有外部干预，系统会朝着越来越混乱的方向发展。对抗熵增的一个办法就是引入负熵，让系统变得更加有序。而在代码中引入负熵的过程就是“重构”。
调整代码这件事实程序员都会有的习惯，但把这件事做到比较系统，上升为”重构“这个层次。
Martin Fowler 的本事就在于他极强的阐述能力，很多名词经过他的定义就会成为行业的流行语（Buzzword），重构就是其中之一。、
重构这个说法可比”调整代码“听上去高级多了，
时至今日，很多人都会说，”这个系统太乱了，需要重构一下“
warning
但是遗憾的事，很多程序员对重构的理解是错的
重构是一种微操作
误解1：
这个系统太乱了，需要重构一下，接着问，你打算怎么重构呢？一些人会告诉你，他们打算另立门户，重新实现这些功能。
对不起，你打算做的事叫重写，而不是重构。
《重构》是一本畅销书，但以我的了解，很少有人真正读完它，因为 Martin Fowler 是按照两本书（Duplex Book）来写的，这是他常用写书的风格，前半部分是内容讲解，后半部分是手册。
重构就是调整代码，调整代码的方法有很多，重写只是其中之一。
重构，本质上就是一个“微操作”的实践。如果你不能理解“微操作”的含义，自然是无法理解重构的真正含义，也就不能理解为什么说“大开大合”的重写并不在重构的范围之内。
重构也属于微操作的行列，与我们介绍的任务分解结合起来，你就能很好的理解重构的定义了："你需要把做的代码调整分解成若干可以单独进行的“重构”小动作然后，完成它。"
你现在理解了，重构不仅仅是一堆重构手法，更重要的是，你需要有的是“把调整代码的动作分解成一个个重构小动作”的能力。
重构地图
学习重构，先要知道重构的定义。关于这点，Martin Fowler 给出了两个定义，一个名词和一个动词。
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
之所以要了解重构的定义，因为重构的知识地图就是围绕着这个定义展开的。首先，我们要对软件的内部结构进行调整，第一个要回答的问题是，我们为什么要调整。
Martin Fowler 对于这个问题的回答是：代码的坏味道。代码的坏味道，在我看来，是这本书给行业最重要的启发。很多人常常是无法嗅到代码坏味道的，因此，他们会任由代码腐坏，那种随便添加 if 或标记的做法就是嗅不出坏味道的表现。
我经常给人推荐《重构》这本书，但我也常常会补上一句，如果你实在没有时间，就去看它的第三章《代码的坏味道》。
再来，重构是要提高可读性，那重构到什么程度算是一个头？
既然重构的核心也是分解，它就需要大量的锤炼。
就像之前提到任务分解原则一样，我在重构上也下了很大的功夫做了专门的练习，才能让自己一小步一小步地去做。
但一个有追求的软件工匠不就应该这样锤炼自己的基本功吗？如果今天的内容你只记住一件事，那请记住：锤炼你的重构技能。
推荐书籍：
重构，重构即模式
