《重构——改善既有代码的设计》读书笔记（一）
入职以来，被tuangou-goods折磨到不行，一直琢磨着要怎么重构它。因此在动大工之前，决定先恶补一下重构的理论知识。
于是，强烈推荐大家也读一读Martin Fowler大神的这本书。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊我是分隔符，以下是我总结的干货＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
一、什么是重构？
- 对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
二、为什么要重构？
- 重构改进软件设计
- 通过不断重构，可以发现并修改软件项目中不合理的地方，提升软件的设计，使软件始终处于一种可维护的状态
- 重构帮助找到bug
- 通过重构，可以发现软件中设计复杂和不合理的地方，往往代码逻辑特别复杂的地方就是bug常常产生的地方
- 重构提高编程速度
- 重构能提高代码质量，改善设计、提升可读性、减少错误
- 良好的设计维持开发速度的根本——重构可以帮助软件维持健康的状态
三、何时重构？
- 首先，不提倡专门划出时间和计划来重构，重构应该随时进行
- 当你多次做同样的事时（三次法则），你就应该重构
- 添加功能时重构：重构可以使项目更加易于添加新功能
- 修补错误时重构：bug产生的一大原因就是代码设计的不合理，而这往往意味着需要重构
- 复审代码时重构：Code Review能帮助项目知识的传播，当然也能在传播过程中暴露项目的问题（一个特殊的例子就是结对编程）
四、何时不重构？
- 项目实在是太烂，烂到开发一个新的都比重构快。。。
- 项目进度很紧，接近最后期限时
五、如何说服项目经理和产品经理项目需要重构？
咳咳。。。本文算不算
六、重构的基础
- 良好的测试环境和测试框架
- 重构建立在测试基础之上，由重构的定义可以看出，需要保持项目重构前后的可观察的外部逻辑行为不变
- 因此，每做一点重构之前，第一步就是测试覆盖
- 重构流程：测试一小点->重构一小点->测试一小点->重构一小点。。。循环往复，不断迭代
七、重构与性能
- 先通过重构写出可调的软件，再通过计量软甲测试系统性能，做到有针对性的优化。因此，重构可以提高系统的可优化性，间接提高系统性能。
七、什么样的代码需要重构？
- Duplicated Code（重复代码）
- 重复的代码会难以维护，违反了DRY原则
- Long Method（过长函数）
- 使用小函数能提高代码的解释能力、共享能力和选择能力；
- 现代的OO语言已经完全免除了进程内的函数调用开销——性能无忧
- 每当你觉得需要通过写注释来说明的时候，就是应该写一个独立函数的时候
- 良好的函数名能能够帮助理解
- 注释、条件表达式、循环、过多的内部变量 值得关注
- Large Class（过大的类）
- 过大的类意味着逻辑并没有良好的拆分
- 不利于代码的维护
- Long Parameter List（过长的参数列表）
- 太长的参数难以理解
- 太多的参数会造成前后不一致、不易使用
- Divergent Change（发散式变化）
- 当一个对象因为多种变化而修改时，就是发散式变化
- 一般来说，每个对象只应该因一种变化而需要修改
- Shotgun Surgery（霰弹式修改）
- 一个类受多种变化的影响
- 变化和修改应该是一一对应关系
- Feature Envy（依恋情结）
- 函数对某个类的兴趣高过对自己所处的类的兴趣
- 根本原则：总是将一起变化的东西放在一起
- Data Clumps（数据泥团）
- 两个类中相同的字段，函数签名里经常一起出现的相同参数
- 意即具有相关性的数据参数
- 需将这些具有极强相关性的数据提炼到一个类中
- Primitive Obsession（基本类型偏执）
- 大量的基本类型数据其实含有内在逻辑，无需偏执
- 可以将相关的组成对象，并赋予一定的逻辑
- Switch Statement（Switch语句）
- 有Switch的地方常常意味着这个地方可以使用多态
- 显然，多态更好维护，具有更好的扩展性
- Parallel Inheritance Hierarchies（平行继承关系）
- 当不同的继承体系之间实际上有内在关联性时
- 一般策略：让一个继承体系的实例引用另一个继承体系的实例
- Lazy Class（冗赘类）
- 并没有什么用类，或实际功能用到很少的类
- Speculative Generality（夸夸其谈未来性）
- 过度设计，代码中出现了所谓的“未来会用到的”代码
- 会造成系统难以维护和理解（一堆没用的代码写在那里，读的人肯定一头雾水的啊）
- Temporary Field（令人迷惑的临时字段）
- 对象内某个实例变量仅为某种特定情况而设定
- Message Chains（过度耦合的消息链）
- 用户向A请求B，再通过B请求C，然后很长。。。
- 意味着客户代码和查找过程中的导航结构紧密耦合
- Middle Man（中间人）
- 自己没干什么，大部分的函数都委托给别的类
- Inappropriate Intimacy（狎昵关系）
- 两个类之间过多的关注对方的private成分
- Alternative Classed with Different Interfaces（异曲同工的类）
- 两个干着差不多事情的类。。。
- Incomplete Library Class（不完美的类库）
- 所引用的类库功能不全或不完美
- Data Class（纯稚的数据类）
- 过分单纯的数据类，应将部分相关逻辑加入这些数据类
- Refused Bequest（被拒绝的遗赠）
- 子类通过继承体系拿到了它不愿拥有的成员变量和函数
- 此时证明继承体系的设计有问题
- Comments（过多的注释）
- 当需要一大堆注释来说明一个函数或字段时，那就说明了其复杂性
- 此时就需要合理的逻辑拆分和重构
＊＊＊＊＊＊＊＊＊＊＊我是干货的分隔符＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
具体的针对不同重构场景的重构技术，将在下一篇里总结。
持续学习中。。。
