代码的坏味道这一章集中论述该何时重构。具体的重构方法在后面的章节。
“没有任何度量规矩比得上见识广博者的直觉。你必须培养自己的判断力，学会判断一个类中有多少实例变量才算太大，一个函数内有多少代码才不算太长。”
——Martin Flower
- 改名
深思熟虑给函数，模块，变量和类命名，使其清晰的表明自己的功能和用法。
重构手法之一：改名（改变函数声明，变量改名，字段改名）
- 消除重复代码——提炼函数
同一个类的两个函数含有相同的表达式——提炼函数。
重复的代码段位于同一个超类的不同子类中——函数上移。
- 拆分过长函数
“活的最长，最好的程序往往都比较短”
“函数越长，就越难理解”
- 过长参数列表
如果发现几项参数经常出现，可通过引入参数对象将其合并为一个对象。（封装）
如果发现从现有的数据结构抽出很多数据项作为参数，不如直接传递完整的对象
以查询替代参数：可以像某个参数查询获得另一个参数的值。 - 全局变量
全局变量的问题：代码库的任何一个角落都可以修改，且无法探测。（代码病毒）
处理方法：封装变量。用函数封装起来，再搬到类或模块里，控制其访问权限。
- 发散式变化与霰弹式修改
发散式变化：遇到变化时固定修改某一部分代码。
霰弹式修改：代码的坏味道其中一种，遇到变化需要修改很多地方。
减小模块的耦合，实现模块的独立。在添加修改功能时实现代码变更的独立。
- 依恋情节
模块化：最大化区域的内部交互，最小化的跨区域交互。
依恋情节：一个函数和另一个模块的函数或者数据交流格外频繁，远胜于在自己内部的交流。
- 数据泥团
“两个类中相同的字段，许多函数签名中相同的参数….”
在必要时提炼类。引入参数对象，保持对象完整使之参数列表较短。
语义和形式的权衡。
使用多态替换switch
循环语句
以管道取代循环。冗赘的元素
随着重构类变得越来越小，适时庄严赴义。夸夸其谈通用性
如果用不到，就不值得。用不上的装置只会挡路。中间人
封装往往伴随着委托。
委托应当适度，过度委托就会变成冗余。
- 过大的类
造成重复代码。
提炼类，提炼超类。
- 注释
“当你感觉需要写注释时，请先尝试重构。”
注释的应用场景：
这段代码做了什么
记录将来的打算
为什么做