谈到重构，大家一定看过 Martin Fowler 在 1999 年写下那本软件行业的名著《重构：改善既有代码的设计》Refactoring: Improving the Dessign of Existing Code），但是遗憾的是，很多程序员对重构的理解都是错误的。
大多数人理解的重构只是重写，比如系统太乱了，要重构一下，怎么重构，就是新写系统，重新实现这个需求或功能即可
比如，一个Service中有一个通用的方法，它并不适合在这个有业务含义的类里面，需要提取到一个通用类里面，一般简单粗暴的做法是：
创建一个新类，把这个方法剪切过去，然后修改各种报错
而真正重构的手法是这样的：
1.添加一个新的通用类
2.在这个Service类中，添加这个新类的引用
3.把原来的Service类中的方法，移动到新的类中
4.idea工具会自动去修改各处调用的方法
乍一看，好像两种写法一样啊，但是你自己看分解的步骤里，每一步都可以很快完成，而且做完每一步后都可以停下来的，这就是真正的重构：重构，本质上就是一个“微操作”的实践。这是简单粗暴的方法所做不到的，你修改报错的时候，不知道什么时候可以修改完，你也不敢乱修改，在加上新需求很多，着急上线的时候，更加无法操作，当然上面只是一个很简单的例子，可以简单粗暴也能很快解决，但如果稍微有点规模的修改，如果不能按照真正重构的方式进行，就真的会出现不知道修改到哪里了，会不会遗漏些什么，上线会不会引发新的bug，这样所谓的重构(重写)的方法会让项目面临很大的风险，一旦开始，不能停止。
所以说：重构不仅仅是一堆重构手法，更重要的是，你需要有的是“把调整代码的动作分解成一个个重构小动作”的能力
重构不仅是愿景（名词），也不仅是行为（动词），还应该成为程序员必备的习惯和工作方式。但要成为习惯，甚至是深入骨髓的那种，是需要有积极意识和大量练习的。经常有人说，先把功能实现了，后面再去重构，但后来的情况往往是不重构，或是债务过多重构代价太大，原因大多都是任务分解不到位，微操作缺失，缺乏合理有效的单元测试等等，所以程序员的自我修养也是要体系化的，所谓功到自然成，与诸君共勉之
