书名：《重构 改善既有代码的设计》
作者：[美]Martin Fowler
译者：熊节
出版社：人民邮电出版社
1.重构，第一个案例
Talk is cheap, show me the code. 有这么点味道，先上代码案例~
如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。
案例主要对statement函数进行了解构，Stract Method。现代编译器IDE都支持。
“任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。”
绝大多数情况下，函数应该放在它所使用的数据的所属对象内，Move Method。
去除接收结果后无变化的临时变量，Replace Temp with Query。
switch分支，可能能够放到对应的类中处理。
2.重构原则
重构(名词)：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构(动词)：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
“两顶帽子”：添加新功能，以及重构。添加新功能时，你不应该修改既有代码，只管添加新功能。通过测试(并让测试正常运行)，你可以衡量自己的工作进度。重构时你就不能再添加功能，只管改进程序结构。此时你不应该添加任何测试(除非发现有先前遗漏的东西)，只在绝对必要(用以处理接口变化)时才修改测试。
- 重构改进软件设计 - 消除重复代码
- 重构使软件更容易理解 - 准确说出我所要的，让第二个程序员更容易理解
- 重构帮助找到bug - 构建更强壮的软件
- 重构提高编程速度
三次法则（事不过三，三则重构）：
第一次做某事可以放手去做；第二次会感到反感，但是还是可以去做；第三次再做类似的事，则要重构。
- 添加功能时重构
- 修补错误时重构
- 复审代码时重构 - 结对编程
程序的两面价值：
1.今天可以为你做什么；
2.明天可以为你做什么。
不要用推测性设计，容易全面崩盘。重构可以让程序至始至终保持一致的行为，并且有机会添加更多价值不菲的质量。如果一个中间层的使用场景是单一的，那么期待其表现多态性的愿望则落空了，需要把它拿掉。
重构可以带来更简单的设计，同时又不损失灵活性，这也降低了设计过程的难度，减轻了设计压力。
3.代码的坏味道
你必须培养出自己的判断力，学会判断一个类内有多少实例变量算是太大、一个函数内有多少行代码才算太长。
- 重复代码（Duplicated Code）
- 过长函数（Long Method）- 关键不在于函数的长度，而在于函数”做什么“和”如何做“之间的语义距离
- 过大的类（Large Class）
- 过长参数列（Long Parameter List）
- 发散式变化（Divergent Change）- 某个类经常因为不同的原因在不同的方向上发生变化
- 霰弹式修改（Shotgun Surgery）- 每遇到某种变化，必须在许多不同的类中做很多小修改
- 依恋情节（Feature Envy）- 函数对某个类的兴趣高过自己所处类的兴趣
- 数据泥团（Data Clumps）- 两个类中相同的字段、许多函数签名中相同的参数
- 基本类型偏执（Primitive Obsession）- 以对象替换基本类型的数据
- Switch惊悚现身（Switch Statements）- 少用switch(或case)语句
- 平行继承体系（Parallel Inheritance Hierarchies）- 每当你为一个类增加子类，必须为另一个类增加相应的子类
- 冗赘类（Lazy Class）- 类应该适应其体积，并有一定的作用
- 夸夸其他未来性（Speculative Generality）- 噢，我想我们总有一天需要做这事
- 临时字段（Temporary Field）- 某个实例变量仅为某种特定情况而设
- 过度耦合的消息链（Message Chains）
- 中间人（Middle Man）- 过度运用委托，不与真正负责的对象打交道
- 过多的注释（Comments）
- …