第三章

代码的坏味道

• 重复代码
• 过长函数
• 过大的类
• 过长参数列
• 发散式变化（某个类经常因为不同的原因在不同的方向上发生变化）
• 霰弹式修改 （每遇到某种变化，都必须在许多不同的类内做出许多小修改）
• 依恋情节 （某个函数对别的类过度依赖，出现这种情况应当将该函数移动到其过度依赖的类中）
• 数据泥团（如果在很多地方都可以看到相同的数据，应该将他们放到一起，让他们拥有自己的对象）
• 基本类型偏执
• swith使用频繁
• 平行继承（每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类。消除策略：让一个集成体系的实例引用另一个继承体系的实例）
• 冗赘类- 如果一个雷的所得不值其身价，它就应该消失
• 夸夸其谈未来性（企图以各种各样的钩子或者特殊情况来处理一些未来有可能发生的事情， 这么做往往造成系统更难理解和维护，用不上的装置只会挡你的路，把它搬开吧）
• 令人迷惑的暂时字段
• 过度耦合的消息链（使用hide delegate手法进行重构）
• middle man(不要过度使用委托)
• 狎昵关系 (两个类你中有我我中有你，这种类必须拆开划清界限)
• 异曲同工的类 （多个不同的类做着相同的事情）
• 不完整的类库
• 纯稚的数据类 （很多时候对数据的操作都可以写到数据类中）
• 被拒绝的遗赠 （子类不愿意支持父类的接口或者数据）
• 过多的注释 （可能是被注释的代码很糟糕）

第四章 构筑测试体系

本章主要讲了JUnit测试框架的使用，因为本书出版时间较早，当前已基本不具备参考价值

第五章 重构列表

后续章节的大纲和介绍

第六章 重新组织函数

6.1 提炼函数

• 创造新函数，准确命名
• 将提炼出的代码从原函数复制到新建的目标函数
• 仔细检查提炼出的代码，看看其中是否引用了“作用域咸鱼源函数”的变量
• 检查是否有“仅用于被提炼代码段”的临时变量，如果有，在目标函数中将他们声明为临时变量
• 检查被提炼代码段，看看是否有局部变量被改变，如局部变量需在外部使用，最好当做返回值返回
• 将被提炼代码段中需要读取的局部变量，当做参数传给目标函数
• 处理完所有局部变量后，进行编译
• 在源函数中，将被提炼代码段替换为对目标函数的调用
• 编译，测试

6.2 内联函数

何时需要内联函数：
一个函数的本体与名称同样通俗易懂
还有一种情况：
手上有一群组织不慎合理的函数，可以将他们都内联到一个大函数中，再从中提取出组织合理的小型函数

6.3 内联临时变量

一个临时变量，纸杯简单表达式赋值一次，可以将其内联化

6.4 以查询取代临时变量

程序以一个临时变量保存某一表达式的运算结果，可以将这个表达式提炼到一个独立的函数中，讲这个临时变量的所有引用点替换为对新函数的调用，此后，新函数就可以被其他函数使用

6.5 引入解释性变量

表达式如果非常复杂将难以阅读
将复杂表达式的拆分成不同部分，将分段后表达式的结果放入多个临时变量中，以变量名来解释表达式用途

6.6 分解临时变量

原则： 每个变量只承担一个责任，同一个临时变量承担两件不同的事情，会令代码阅读者糊涂
如 某个临时变量在前半部分代表身高，计算过身高后又代表体重

6.7 移除对参数的赋值

对代码赋值降低了代码的清晰度，而且混用了安置传递和按引用传递这两种传递方式
尽可能将参数视为final的

6.8 以函数对象取代函数

有一个大型函数，其中对局部变量的使用很难对其使用Extract Method方式，可以将这个函数放进一个单独对象中，如此一来局部变量就变成了对象内的字段，然后可以在同一个对象中将这个大型函数分解为多个小型函数

6.9 替换算法

慎之又慎，除非有十足的把握