一、什么是重构

重构就是在不改变软件的可观察行为的前提下，对代码进行修改，改进程序的内部结构。

有两个不同的重构方向：

1. （小改动）不改变软件的可观察行为，对代码内部结构进行调整，不做大的变动，不做架构上调整，提高代码的可理解性，简单化，降低代码的修改维护成本。
2. （大改动）不改变软件的可观察行为，通过一些重构手法，如设计模式、设计原则，调整软件的架构、模块等内部结构，优化代码，提高整体代码的质量。

二、为什么要重构

技术不断发展，程序会慢慢老化，老程序会存在以下问题：

1. 大量重复代码让人很难理解，新增特性需要涉及阅读理解其他一大堆的无用代码。
2. 程序接口文档缺失，模块内外耦合严重。
3. 模块内的功能实现堆砌式，随便使用全局变量、控制变量，不断增加控制分支，导致维护难度不断增加，程序异常也不断增加
4. 运行时逐渐出现内存、CPU、存储空间等资源不足，使用过高等问题出现，急切优化程序
5. 功能类似，代码重复，工作量增加，效率很低，不利于软件发展。等等

当一个软件产品出现了以上问题的，就需要重构该软件产品了。

一句话总结就是：再好的架构，其生命力也是有限的。随着时间的推移、环境的变化以及新技术、新功能特性的引入，架构也会腐化。面对腐化了的架构，要毫不犹豫地去重构它。

三、重构的好处

1. 重构可以改进程序内部结构，跟着技术不断发展，防止逐渐腐败
2. 重构可以使软件产品的架构更清晰，简化代码裸机，去除重复代码，使人更容易理解，更容易维护，更容易持续演进
3. 重构可以使软件产品更容易拓展，提高开发效率。符合program smart标准：

• performance高效
• protable可移植
• security安全
• maintainable可维护
• reliability可靠
• readable可读
• testable可测试

四、重构的分类

重构有多个层次，每一层的重构意义不同：

1. 第一层：功能正确，外在功能表现与需求一致
2. 第二层：无漏洞风险，满足基本安全规范要求
3. 第三层：代码整洁，满足基本的编码规范要求，代码简洁易懂易维护
4. 第四层：架构优雅，高内聚低耦合，易拓展、可移植，使用算法精巧
5. 第五层：软件产品在不断的演进，不断更新。

具体的重构类别：

1. 架构级重构：属于大规模的重构活动，要求比较高，是一项大功能，需要架构师、专家参与并落实
2. 模块级重构：开发人员可以评估落实方案，要求一般。
3. 函数级重构：最多的重构活动，在日常的开发过程即可完成。

五、重构的原则

重构的前提是：先识别软件代码的坏味道，制定好重构方案后，才能进行重构。

重构时最重要的一点是：需要将新增代码与重构分开，重构前与重构后需要有测试用例保障，确保继承性功能不被破坏。

1. 新增新功能或者修改bug时，不要将重构代码放在一起带进去，新增新功能只管添加新功能代码即可。
2. 重构时，也不能带有新功能，只管改进原来的程序结构即可
3. 一次只做一件事，一次重构只针对一种类型功能进行重构

然后依赖的六大设计原则【SOLID原则】去识别并重构：

• 单一职责原则（SRP）：一个类、接口、方法只负责一项职责，也就是只干一件事。
• 开闭原则（OCP）：一个软件实体（类或接口、模块和函数）对外拓展开放，对修改关闭。
• 里氏替换原则（LSP）：子类对象可以替换成父类对象，子类对象可以拓展父类对象而不改变父类的方法和属性
• 迪米特原则[最小知道原则]（LOD）：一个对象应该对其他对象保持最少的了解，降低类与类之间的耦合度，通俗来讲就是只关心朋友，不在意陌生人；代码中尽量不要出现陌生人
• 接口隔离原则（ISP）：一个类对另一个类的依赖建立在最小接口之上。
• 依赖倒置原则（DIP）：也叫依赖注入。高层模块不依赖底层模块，两者都依赖抽象。

并结合正交设计原则进行重构思考：

• 消除重复（被动）。体现了低耦合
• 分离关注点（主动）。也叫分离不同方向变化，是整个模块化思想的延伸，也就是单一职责和组合复用的表现
• 缩小依赖范围（主动）。体现高内聚，迪米特法则的表现
• 依赖与稳定（主动）。耦合点的体现，依赖稳定的接口；是接口分离原则换了一个说法
  

六、重构的时机与方向

重构应该是随时进行，不要为了重构而重构，重构是为了将我们的程序优化得更好，更更好的为我们省事，高效。所以我们需要把握好重构时机，及时重构。

何时重构：

• 在新增特性代码的时候，发现有更好的实现，方便未来拓展，使开发更快速、更舒畅，可以考虑重构。
• 修改bug的时候，发现原来的旧代码不够清晰，并且很难发现错误，考虑重构
• 在我们组织代码检视活动的时候，根据经验，存在问题，有改善设计的空间，考虑重构。

何时不重构：

• 如果代码太混乱，设计完全错误，不考虑重构，直接重写，重新设计。
• 如果没有任何重构思路的时候，不要考虑重构。
• 如果时间很紧，重构的工作量又很大，会影响整个工作，建议推迟重构。

重构那些地方：

• 看到有重复的代码，做重复的事情，果断重构。如果做一件事情，重复超过三次，那么第三次就得选择重构去做。
• 看到代码中接口或逻辑混乱，接口文档缺失，模块内外耦合严重时，该地方考虑重构
• 看到代码中各种全局性的控制变量多，并且不断的异常性增加，该地方考虑重构