重构，改善既有代码的设计 笔记

什么是重构

1、不改变代码外在行为
2、对代码进行优化，改进程序的内部结构
3、提高可读性，降低修改成本

为何重构

1、改进软件设计
2、软件（代码）更容易被理解
3、帮助找到bug
4、提高编程速度

何时重构

1、三次法则（第三次写同样的代码）
2、添加功能的时候
3、修bug的时候
4、review代码的时候（最好review者和被review者搭配重构）

重构难题

1、数据库， 代码和数据库结构紧密耦合在一起，结构难以修改
2、修改接口（已发布的接口），要维护新老接口，但这样会有过多额外冗余接口
3、难以通过重构手法完成的设计改动
4、何时不该重构，一是代码太混乱，还不如重写来的简单，还是就是项目已经到最后期限

重构与设计

重构降低了预先设计的压力。有了重构，预先设计不必过于追求正确完美的解决方案，只需要一个足够合理的方案；然后在实施的过程中，不断的重构，提高方案的灵活性。

重构与性能

1、时间预算法，对代码每个组件做好时间预算
2、持续关注法，持续关注保持系统的高性能。这个方式很常见，但作用有限。任何修改，要平衡性能和代码可读的关系
3、优化核心代码（10%的代码），所有代码中，90%的优化工作是浪费的，需要关注性能热点

代码的坏味道

1、重复代码
2、过长的函数
3、过大的类
4、过长的参数列
5、发散式改变，如果某个类经常因为不同原因在不同方向发生变化，建议对象拆成几个，这样每个对象可以
为一种变化而进行修改
6、霰弹式修改，如果某种变化需要改动多个类，通常可以把一系列相关行为放进同一个类
7、依恋情结，函数应放置在其使用数据最多的类里面
8、数据泥团，类似的数据，应删除冗余，组合到同一个类里面
9、基本类型偏执
10、switch惊悚现身，少用switch，考虑多态来替换它
11、平行继承体系，让一个继承体系引用另一个继承体系的实例。
12、冗余类，删除性价比低的类
13、夸夸其谈未来性，用一些钩子和特判做一些未来可能发生的事。
14、令人迷惑的暂时字段，消灭长参数的时候，可以封装成一个类比较好，而不是用临时变量。
15、过度耦合的消息链，消息链太长需要重构。
16、中间人，过度运用委托
17、耦合太多的两个类，互相访问私有变量需要重构。需要划清界限。
18、异曲同工的类
19、不完美的库类
20、纯雅的数据类，可以把一些逻辑放到数据类本身。也就是增加方法.
21、被拒绝的遗赠，子类不需要父类的接口或者数据。不用急着修改继承体系。
22、过多的注释