让review的人更容易理解，让下一个接手你代码的人，更容易理解。也许下一个接手你代码的人就是你自己。有的时候，一段代码拿过来，是不是你自己写的，你都确定不了，对吧？

• 重构的好处

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

重构帮助找到bug

• 重构提高编程速度

3、重构的时机

• 事不过三，三则重构

• 添加功能时重构

• 修改错误时重构

• 复审代码时重构

4、为什么重构有用

1. 难以阅读的程序，难以修改；

2. 逻辑重复的程序，难以修改；

3. 添加新行为时需要修改已有代码的程序，难以修改；

4. 带复杂条件逻辑的程序，难以修改；

因此，我们希望程序：

1. 容易阅读；

2. 所有逻辑都只在唯一地点指定；

3. 新的改动不会危及现有行为；

4. 尽可能简单表达条件逻辑；

间接层和重构

间接层的价值：

1. 允许逻辑共享；

2. 分开解释意图和实现；

3. 隔离变化；

4. 封装条件逻辑；

5、重构的难题

（1）数据库

数据迁移

（2）修改接口

不要过早发布接口，请修改你的代码所有权政策，使重构更顺畅。

（3）难以通过重构手法完成的设计改动

（4）何时不该重构

/**

• @startTime 2020-12-20 11:50

• @endTime 2020-12-20 15:30

• @startPage 65

• @endPage 102

• @efficiency 102/5 = 20.4页/天

• @needDays 412/20.4 = 20天

• @overDay 2020-12-16 + 20天 = 2020-01-04

*/

6、重构和设计

很多人都把设计看做软件开发的关键环节，而把编程看做只是机械式的低级劳动。他们认为设计就像画工程图而编码就像施工。

哪怕你完全了解系统，也请实际度量它的性能，不要臆测。臆测会让你学到一些东西，但十有八九你是错的。

7、重构和性能

首先写出可调的软件，然后调整它以获得足够的速度。

三种编写快速软件的方法：

（1）时间预算法

通常用于性能要求极高的实时系统。

分解设计时要做好预算，给每个组件预先分配一定的资源，包括时间和执行轨迹。每个组件决不能超出自己的预算，就算拥有组件之间的调度预配时间的机制也不行。

这种方法高度重视性能，对于心率调节器一类的系统是必须的，因为这样的系统中迟来数据就是错误的。但对一些管理系统来说，如此追求性能就有点过分了。

（2）持续关注法

这种方法要求任何程序员在任何时间做任何事情时，都要设法保证系统的高性能。

这种方法看起来很常见，感觉上很有吸引力，但通常不会起太大作用。

（3）性能优化阶段

编写程序时，不用将过多的精力关注在性能上，在代码开发完毕之后，会有一个性能优化阶段，一旦进入该阶段，就按照某个特定程序来调整程序性能。

在性能优化阶段，首先应该用一个度量工具来监控程序的运行，让它告诉你程序中哪些地方大量消耗时间和空间。这样就可以找出性能热点所在的一小段代码。然后应该集中关注这些热点代码，并使用持续关注法中的优化手段来优化它们。每走一步都需要编译、测试、再次度量。

8、重构起源何处

第三章 代码的坏味道

1、重复代码

同一个类中两个函数含有相同的表达式时，就要提炼出重复的代码，然后让这两个地点都调用被提炼出来的那一段代码。

2、过长函数

间接层所带来的全部利益，解释能力、共享能力、选择能力。

应该更积极的分解函数，每当感觉需要注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名，我们甚至可以对一组甚至一行代码做这件事。哪怕替换后的函数调用动作比函数自身还长，只要函数名称能够解释其用途，我们也该毫不犹豫的这么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。

（1）提炼函数

（2）以查询取代临时变量

（3）引入参数对象或保持对象完整

（4）以函数对象取代函数

将这个特函数放进一个单独对象中，如此一来局部变量就变成了了对象内的字段，然后你可以在同一个对象中将这个大型函数分解成多个小型函数。

本书在不断强调小型函数的优美动人。

（5）条件表达式和循环常常也是提炼的信号。

分解条件表达式；

将循环和其内的代码提炼到一根独立函数中。

3、过大的类

如果想利用单个类做太多事情，其内就会出现太多实例变量。一旦如此，重复代码也就接踵而至了。

可以利用提炼类将几个变量一起提炼至新类中。

4、过长参数列

5、发散式变化

6、散弹式修改

如果遇到某种变化，都必须在很多不同的类中做一些小修改的时候，你就可以将这些一起变化的代码提炼到一个新的类中。

7、依恋情节

函数对某个类的兴趣高多对自己所处类的兴趣，这时就需要转移函数的位置了。

8、数据泥团

一个好的评判方法是：删除众多数据中的一项时，其它数据有没有因而失去意义？如果它们不再有意义，这就是一个明确的信号，你就应该产生一个新对象。

减少字段和参数的个数，当然可以去除一些坏味道，但更重要的是：一旦拥有新对象，就有机会让程序散发出一种芳香。得到新对象后，你就可以着手寻找依恋情节，这可以帮你指出能够移至新类中的种种程序行为。不必太久，所有的类都将在它们小小社会中充分发挥价值。

9、基本类型偏执

对象技术的新手通常不愿意在小任务上运用小对象，像结合数值和币种的money类、电话号码、邮政编码等的特殊字符串，看似简单，此时可以运用以对象取代数据值，将原本单独存在的数据值替换为对象，从而走出传统的洞窟，进入炙手可热的对象世界。

10、switch惊悚现身

面向对象程序的一个最明显特征就是：少用switch语句。

从本质上说，switch语句的问题在于重复。你常会发现同样的switch语句散布于不同地点。如果要为它添加一个新的case子句，就必须找到所有switch语句并修改它们。 面向对象中的多态就可以带来优雅的解决方法。

11、平行继承体系