为什么要搞代码重构
有很多的书在讲这个问题，包括经典的《Clean Code》以及《重构：改善既有代码的设计》这些书中，都给出了很多的原因，实际上之所以会导致重构的发生，归根到底就是
代码已经脱离了我们的掌控了
程序写出来是给人看的,附带能在机器上运行，忘记了是哪里看到的这句话。这句话深刻的揭示了编程的本质。当面对一系列糟糕的代码的时候，再好的程序员都只能事半功倍，要花大量的时间去理解糟糕的带啊吗。这也就是为什么要提倡clean code的原因。因此
- clean code也就成为了重构的一个最重要的原因。重构是为了消除代码中的坏味道。
坏味道有很多种，在重构一书中，列举了很多，如下所示：
- 神秘命名（Mysterious Name）
- 重复代码（Duplicated Code）
- 过长函数（Long Function）
- 过长参数列表（Long Parameter List）
- 全局数据（Global Data）
- 可变数据（Mutable Data）
- 发散式变化（Divergent Change）
- 霰弹式修改（Shotgun Surgery）
- 依恋情结（Feature Envy）
- 数据泥团（Data Clumps）
- 基本类型偏执（Primitive Obsession）
- 重复的switch （Repeated Switches）
- 循环语句（Loops）
- 冗赘的元素（Lazy Element）
- 夸夸其谈通用性（Speculative Generality）
- 临时字段（Temporary Field）
- 过长的消息链（Message Chains）
- 中间人（Middle Man）
- 内幕交易（Insider Trading）
- 过大的类（Large Class）
- 异曲同工的类（Alternative Classes with Different Interfaces）
- 纯数据类（Data Class）
- 被拒绝的遗赠（Refused Bequest）
- 注释（Comments）
可以看到上面的大部分的坏味道都是代码基础层面的问题，重复代码，过长函数等等。修改了这些问题，能够让代码更容易阅读，这些都是对代码的小改进，通过对代码的小步快跑式的改进，来逐步的提升代码的质量。
就像演义中谋士一般都会给出上中下三策一样，我认为代码的重构也是分三个级别的。
架构上的重构
如果软件的架构上本身已经腐朽了，或者架构本身已经脱离了时代了，那么用上面的哪些技巧或者坏味道改进是不解决问题的。在这种情况下，对架构进行彻底调整或者直接重新设计架构重写代码，才是正确的方式类的重构
对于面向对象而言，有一句很有名的话，虽然不一定正确，但是还是很有代表性的，即“万物皆类”。类属于一个较大颗粒度的东西，因此如果类本身设计有问题或者实现有问题的话，则需要对其进行重构调整，比如说类没有对扩展开放，对修改封闭等等。坏味道的重构
最基层的就是重构书中提到的种种基于坏味道的重构了，都是一小点一小点的改进，让代码更加易读易懂。
构建测试体系
重构最怕在没有意识到的情况下，修改了原有的功能。很多时候，即使经过充分的测试，我们也是很难发现引入了bug的了。因此要构建测试体系，尽量尽早发现bug，在最初的阶段就将其消灭掉。
关于《重构：改善既有代码的设计》这本书
这本书的价值有80%都在最开始的例子上，后面的内容说实话，有些啰嗦和夸夸其谈了。实际上，如果没有多年的编程经验，是体会不到这些坏味道的坏处的。而如果有了多年的编程经验了，这些坏味道的解决方式也都是大家知道的，这本书也没有什么新意，这就很尴尬了。
这本书剩下的20%的价值就在后面的400多页的各个重构手法里面提到的步骤上了，精华在于按照书中的步骤走，会让你在重构时能够少引入错误，仅此而已。
因此对于这本书，最开始的那个例子要认真阅读，学习。
真正的重构要读什么书
实际上如果真的想要学习好重构，这本书价值不高。更应该看《设计模式》的书。设计模式才是我们真正应该去用心学习吸收体会的。设计模式的最基础的理念就是一条：
- 将变化的部分与不变的部分剥离
这样就解决了最大的问题：扩展。
同时设计模式也是无数的编程高手的经验总结，这才是真正有价值的东西。