重构小记（重构，改善既有代码的设计读后总结）
我们要时时刻刻保持一颗项目要重构的心。
在非技术出身的领导看来，能用的代码就是好代码，只关注功能。
在工程师看来，代码不仅要好用，更要好看，好理解，好修改。
重构就是让你的代码更时尚，更方便，更高效。
什么是重构
在不改变现有行为的前提下，通过改变内部结构，提高项目的可理解性和易修改性。
所以重构的目的就是使项目更容易理解和修改。
重构时机
代码复杂（复杂到不想改了或者改不动了）
时间允许（进度驱动转为质量驱动）
代码洁癖（容不得一点坏味道）
项目迁移（项目交接后迁移并重构）
重构常用快捷键（以idea为例）
shift + F6（一键修改变量名，变量名不规范常用）
ctrl + F6（一键修改类名或方法名，也是命名不规范修改常用）
ctrl + alt + m（将选中代码一键抽出成函数，过长函数常用）
ctrl + t（将选中代码提取至各种块中，比如if-else；try-catch等）
具体重构细节
重复代码
重构时应该把重复代码提炼出来，可以提炼到公共父类，或者静态函数等地方。
过长函数
重构时应该避免过长的函数，应该尽量的将大函数分解成多个小函数，并标明每个小函数的意思。
过大的类
一个类最好不要做太多事情，也不要有太多的代码，否则就会难以理解。
过长参数列
方法的入参如果超过5个，就试着将一些入参抽成一个对象，用对象来作为入参。
发散式变化
一个类中，如果每次修改都要设计到几个不同的函数，那么就要考虑将这个类拆分了。
针对某一外界变化的所有相应修改，都应该只发生在单一类中。
霰弹式修改
与发散式变化相反
当发现某种变化必须在多个不同类中做许多修改，就应该把这些所有需要修改的代码放入同一个类中。
依恋情节
将总是一起变化的东西放在一块
数据泥团
两个类中相同的字段，应该拥有他们自己的对象
平行继承体系
是霰弹式修改的特殊情况
每当你为某个类怎增加一个子类，也必须为另一个类相应增加一个子类，就该重构了
一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
冗赘类
如果一个类的所得不值其身价，它就应该消失
夸夸其谈未来性
如果一个类其实没多大作用，只是想着以后会怎么样怎么样，就先把他去掉
令人迷惑的暂时字段
如果类中的某些实例变量仅为某种特殊情况而设，那么就需要把这些变量和其相关函数都提炼到一个独立类中。
中间人
如果某个类接口有一般的函数都委托给其他类，那么就是过度调用了。这时候应该去掉委托，直接调用。
亲昵关系
如果两个类过于亲密，有太多相互调用引用的地方，就必须拆散。
注意，继承往往会造成过度亲密，因为子类对父类的了解总是超过父类的主观愿望，这时候就应该用委托代替继承
详细做法就是去掉原继承，将原父类当成子类的一个属性，用到父类的方法时去委托调用就行。
不完美的库类
当引用的库不能满足我们的需求，需要扩展库类的功能时，考虑引入本地扩展（创建子类继承原库中的父类或者父类委托）
被拒绝的馈赠
如果子类不需要继承父类的所有函数和数据，这就意味着继承体系的错误。这时应该去掉继承关系，用父类委托来代替（原父类作为原子类的一个属性）
过多的注释
注释应该是简单明了，而不是为难懂的代码擦屁股，解决这类问题，还需要从代码提炼等方面做起，增加代码的可读性。