《《重构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，如果上头不是很认可，其实这个工作很不好做，改得不好很容易背锅。
