1、起点

1. 当程序需要维护，需要人理解，但又发现理解困难时需要重构
2. 业务不断扩充，最初的设计很难完美，而且代码很可能经手过多个程序员
3. 有时我们发现甚至很难理解自己以前写过的代码，由于时间的积累，也许我们已经有了更优的写法
4. 经济利益驱动，因为它能让添加新功能更快

2、目标

提高编程速度：当需要修改时，能快速找到修改点，并不易引入错误

3、重构与性能优化

重构让代码更容易理解，易于修改（开发者层面、代码层面）。也许代码行数会变多，因为提炼会带来一些包装成本和调用成本。

而性能优化是让程序更快，也许最终代码更难理解（用户层面、程序运行层面）

4、注意点

1. 仅重构需要人理解的代码
2. 重构不修改原逻辑，要准备测试用例，保证不影响原功能
3. 小范围修改后立马测试，能在出错时快速锁定范围
4. 重构是碎片化的，它穿插在日常的开发中

5、关键词

• 语义化（恰当的命名）
• 消除重复
• 不可变的数据是最安全的
• 解耦
• 降低复杂度（过长的函数体、条件判断、参数、临时变量）
• 预测将来可能发生的需求变化以及代码应为此做出的改动
• 纯函数

6、原则

• 单一职责
• 开放-封闭：添加一个新的功能，应该是通过在已有代码基础上扩展代码，而非修改已有代码
• 迪米特法则：一个对象应该对其他对象保持最少的了解

7、一些方法

1. 控制变量的作用域

数据的作用域越大，封装就越重要。限制对它的访问和修改

-> 可以将变量和访问函数搬移到单独的文件里，只对外暴露访问函数
-> 如果组织不了未来的代码之间访问变量，可以为它取个难听的名字以引起注意
-> 当把数据的修改权交出去的时候要慎重，因为此后别人会如何修改它，我是未知的
-> 不过归根结底，还是不可变的数据更可靠

2.重命名

如果需要改名，声明新的变量并赋值后，可以将旧变量赋值为新变量，防止由于遗漏造成报错

3.嵌套的函数

保持警惕，因为很容易在里面编写一些私有数据，这会增加代码的阅读和重构难度

4.提炼函数后的问题

在多个文件中提炼一个顶层函数有时存在这样的问题：这个公共方法通常位于一个文件中，读者不一定能想到来这里寻找它，为了让该函数与其处理的数据在空间上有更紧密的联系，考虑将数据和操作方法包装成一个类，让读者能在类里寻找各种处理数据的能力

5.以查询取代派生变量

当源数据会改变时，派生变量最好是实时计算出来的，避免修改一些源数据时忘了更新派生变量的错误