《《重构2》这本书是我觉得非常有必要看的，对于自己写代码有着比较大的影响，力荐。结合书中和自己实践提炼和总结一些内容分享出来。重构分为服务级别的重构和代码级别的重构，《重构2》这里面主要是说代码级别的。强如阿里，发展的过程中也会出现臃肿问题，后续他们把服务进行了分布式改造和服务化改造。如下摘抄《淘宝技术这10年》的原话。

1. 为什么重构

1.1 重构是什么

重构指在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。

1.2 重构的作用

a、改进软件设计。

b、使软件(代码)更容易理解。                                                                                                                    c、帮助找到bug。

d、提高编程速度。

2. 何时重构

2.1 简单来说，重构不需要刻意去安排时间，不用为了重构而重构，重构是为了把某件事情更好地完成；

2.2 三次法则，即事不过三，同样的程序出现多次就可以考虑重构了；

2.3 添加新功能时重构；

2.4 修补问题功能时重构；

2.5 复审代码时重构；

3. 重构什么

3.1 神秘的命名

命名不合理给阅读带来很大的困扰。给方法、模块、变量和类一个好的名字，才能清晰地表达相应的功能和用法。

3.2 重复的代码

一旦有重复代码存在，阅读这些重复的代码时你就必须加倍仔细，留意其间细微的差异。如果要修改重复代码，你必须找出所有的副本来修改。

3.3 过长的方法

方法越长，就越难理解。越不好维护。

3.4 过长的参数列表

过长的参数，不好理解和维护。

3.5 数据泥团

常常可以在很多地方看到相同的三四项数据：两个类中相同的字段、许多方法签名中相同的参数。这些总是绑在一起出现的数据应该拥有属于它们自己的对象。

3.6 循环语句

循环已经有点儿过时，看是否能用stream替代

3.7 冗赘的元素

可能有这样一个方法，它的名字就跟实现代码看起来一模一样；也可能有这样一个类，根本就是一个简单的方法。起初在编写这个方法时，期望它将来有一天会变大、变复杂，但那一天从未到来。

3.8 夸夸其谈通用性

当有人说“噢，我想我们总有一天需要做这件事”，并企图以各式各样的钩子和特殊情况来处理一些非必要的事情，这种坏味道就出现了。这么做的结果往往造成系统更难理解和维护。

3.9 临时字段

类内部某个字段仅为某种特定情况而设。这样的代码有时让人不易理解。

3.10 过大的类

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

3.11 注释

有时候注释为了掩盖代码的坏味道，作为“除臭剂”使用了。有时注释就作为一个有坏味道的信号了。

4. 重构的技巧

4.1、提炼方法；（反向重构-内联方法）

使用场景如：方法过长、代码复用的角度

一个很好的技巧是：寻找注释。就算只有一行代码，如果它需要以注释来说明，那也值得将它提炼到独立方法中去。

4.2 提炼变量（反向重构-内联变量）

如果表达式非常复杂而难以阅读。这种情况下，局部变量可以帮助我们将表达式分解为比较容易管理的形式。

4.3 引入参数对象

使用场景：数据泥团

4.4 以查询取代临时变量

使用场景：取代临时变量、方便提炼方法

4.5 提炼类 （反向重构-内联类）

使用场景：数据泥团。一般类随着责任不断增加，这个类会变得过分复杂。很快，你的类就会变成一团乱麻。

4.6 拆分循环

让循环只做一件事情，但如果你在一次循环中做了多件不同的事，那么每当需要修改循环时，你都得同时理解这多件事情。拆分循环有利于系统的完善。但是有一点，重构完成之后，如果确实发现会造成性能问题，再合并回来。一般情况下，循环本身也很少成为性能瓶颈。

4.7 stream替换循环

使用场景：stream好处是，允许我们去表达我们想要完成什么而不是要怎样做

4.8 移除死代码

使用场景：无用代码确实会带来很多额外的思维负担。有可能以后又会需要这段代码，就算真的发生，可以从版本控制系统里再次将它翻找出来。

4.9 拆分变量

其他的如果它们被赋值超过一次，就意味它们在函数中承担了一个以上的责任。同一个变量承担两件不同的事情，降低可读性。

4.10 分解条件表达式 （反向重构-合并条件表达式）

将每个分支条件分解成新函数可以带来更多好处：可以突出条件逻辑，更清楚地表明每个分支的作用，并且突出每个分支的原因。

4.11 以卫语句取代嵌套条件表达式

卫语句取代嵌套条件表达式的精髓就是：给某一条分支以特别的重视。如果使用if-else结构，你对if分支和else分支的重视是同等的。

4.12 以命令取代方法 （反向重构-以方法取代命令）

适用场景例如：过长方法，命令对象提供了更大的控制灵活性和更强的表达能力

4.13 方法上移 （反向重构-方法下移）

避免重复代码

4.14 提炼超类

如果我看见两个类在做相似的事，可以利用基本的继承机制把它们的相似之处提炼到超类。

4.15 委托取代子类 （类似-委托取代超类）

继承给类之间引入了非常紧密的关系。与继承关系相比，使用委托关系时接口更清晰、耦合更少。

5. 测试帮助重构

要正确地进行重构，前提是得有一套稳固的测试集合，以帮我发现难以避免的疏漏，这点很重要，只要这方面吃过亏就能认识到。

还有一个问题就是重构代码短期间收益不高，很不容易出kpi，如果上头不是很认可，其实这个工作很不好做，改得不好很容易背锅。