需要重构的特征
没有恒定的标准，只有迹象，是否重构需要培养自己的判断力
1、switch 写法 / 条件表达式
虽然便于扩展，但是这样的分支逻辑很容易随着代码堆积而腐坏 —> 解决方案：类型多态（以多态取代条件表达式（272））
- 实现方式：创建一个继承体系，多个子类 -> 每个子类包含各自独立的计算逻辑，调用者调用一个多态的函数，由语言分发到不同的子类计算过程中
2、如果发现一组函数形影不离得操作同一块数据（通常是将这块数据作为参数传递给函数）
是时候组建一个类了 –> 函数组合成类（144）
- 类能够明确得给这些函数提供一个共用的环境 -> 在对象内部调用这些函数可以少传很多参数
3、对重复的代码 -> 三次法则：事不过三， 三则重构
- 第一次做某件事时只管去做；
- 第二次做类似 的事会产生反感，但无论如何还是可以去做；
- 第三次再做类似的事，你就应该重构
4、重构的最佳时机就在「添加新功能」之前（磨刀不误砍柴工）
- 添加新功能最快的方法往往不是增加新代码，而是 修改现有的代码，使新功能更容易被加入
- 捡垃圾式重构 -> 每个小步骤都不会破坏代码，在多次路过时清理，即便每次清理并不完整，代码也不会被破坏，直到最终清理干净
5、如果看见一块代码比较凌乱，但是这次需求我并不需要修改它，那么就不需要去修改它
只有当我需要理解其工作原理时，对其进行 重构才有价值
6、每当感觉需要以注释来说明点什么的时候 / 看到注释
我们就把需要说明的东西写进一个独立函数中，并以其用途 （而非实现手法）命名；
如果是变量，可以直接修改变量名称 -> 原则：试着让所有注释都变得多余
7、数据结构
好的数据结构，可以让代码关注在怎么实现功能；
糟糕的数据结构会导致很多无用代码，在数据结构间纠缠不清，而不是为系统实现有用功能
-
但实际上，我们是很难一次做对的，在发现数据结构不适用于需求时，应该马上修缮，避免更多复杂的数据代码
-
例如
-
- 总是一同出现、一同作为函数参数传递的数据，最好是规整到同一条记录中，以体现它们之间的联系
- 如果修改一条记录时，总是需要同时改动另一条记录，那么说明很可能有字段放错了位置
- 如果我更新一个字段 时，需要同时在多个结构中做出修改，表明该字段需要被搬移到一个集中的地点，这样每次只需修改一处地方
8、分离数据查询和数据操作
一个比较好的原则：尽量使变量不可变；查询和修改函数分离，确保调用者不会使用有副作用的代码
- 方案：将查询动作分离出来
9、循环 / 复用变量
一个循环做一件事情 -> 多件事情的情况下，拆分循环 -> 以管道取代循环
一个变量表示一个含义 -> 多个含义的情况下，拆分、新增变量
10、过长的函数 / 过长的参数列表 / 过长的操作链路
过长的函数应该模块化 -> 保证我每次修改时，只需要理解相关的上下文，而不是理解整个函数，包括很多无关代码 -> 原则：每次只关心一个上下文
令人困惑的过长的参数列表 -> 可以通过以查询取代参数去除部分参数；或者直接传入原来的数据结构
如果函数操作的那些数据，需要传递很多链路 -> 考虑是否通过提炼函数+搬移函数实现 -> 将总是一起变化的东西放在一块