“如果尿布臭了，就换掉它。”

——Beck奶奶，论保持小孩清洁的哲学

---

代码的坏味道这一章集中论述该何时重构。具体的重构方法在后面的章节。

“没有任何度量规矩比得上见识广博者的直觉。你必须培养自己的判断力，学会判断一个类中有多少实例变量才算太大，一个函数内有多少代码才不算太长。”

​ ——Martin Flower

3.1 改名

深思熟虑给函数，模块，变量和类命名，使其清晰的表明自己的功能和用法。

重构手法之一：改名（改变函数声明，变量改名，字段改名）

3.2 消除重复代码——提炼函数

同一个类的两个函数含有相同的表达式——提炼函数。

重复的代码段位于同一个超类的不同子类中——函数上移。

3.3 拆分过长函数

“活的最长，最好的程序往往都比较短”

“函数越长，就越难理解”

3.4 过长参数列表

• 如果发现几项参数经常出现，可通过引入参数对象将其合并为一个对象。（封装）
• 如果发现从现有的数据结构抽出很多数据项作为参数，不如直接传递完整的对象
• 以查询替代参数：可以像某个参数查询获得另一个参数的值。

3.5 全局变量

全局变量的问题：代码库的任何一个角落都可以修改，且无法探测。（代码病毒）

处理方法：封装变量。用函数封装起来，再搬到类或模块里，控制其访问权限。

3.6 发散式变化与霰弹式修改

发散式变化：遇到变化时固定修改某一部分代码。

霰弹式修改：代码的坏味道其中一种，遇到变化需要修改很多地方。

减小模块的耦合，实现模块的独立。在添加修改功能时实现代码变更的独立。

3.7 依恋情节

模块化：最大化区域的内部交互，最小化的跨区域交互。

依恋情节：一个函数和另一个模块的函数或者数据交流格外频繁，远胜于在自己内部的交流。

3.8 数据泥团

"两个类中相同的字段，许多函数签名中相同的参数...."

在必要时提炼类。引入参数对象，保持对象完整使之参数列表较短。

语义和形式的权衡。

3.9 使用多态替换switch

3.10 循环语句

以管道取代循环。

3.11 冗赘的元素

随着重构类变得越来越小，适时庄严赴义。

3.12 夸夸其谈通用性

如果用不到，就不值得。用不上的装置只会挡路。

3.13 中间人

封装往往伴随着委托。

委托应当适度，过度委托就会变成冗余。

3.14 过大的类

造成重复代码。

提炼类，提炼超类。

3.15 注释

“当你感觉需要写注释时，请先尝试重构。”

注释的应用场景：

• 这段代码做了什么
• 记录将来的打算
• 为什么做