《重构改善既有代码的设计》(第三章)【代码的坏味道】

àì夳堔傛蜴生んèń 2021-07-05 01:49 631阅读 0赞

知道"如何"不代表知道"何时"，决定**何时重构及何时停止**和知道**重构机制如何运转**一样重要！

Kent Beck提出了用味道来形容重构的时机。

作者并不试图制定一个何时必须重构的精确衡量标准。从经验来看，没有任何量度规矩比得上见识广博者的直觉。对于开发者，必须培养自己的判断力，学会判断一个类内有多少实例变量算是太大，一个函数内有多少行代码才算太长。

## 坏味道条款 ##

*  神秘命名(Mysterious Name)
 *  重复代码(Duplicated Code)
 *  过长函数(Long Function)
 *  过长参数列表(Long Parameter List)
 *  全局数据(Global Data)
 *  可变数据(Mutable Data)
 *  发散式变化(Divergent Change)
 *  散弹式修改(Shotgun Surgery)
 *  依恋情结(Feature Envy)
 *  数据泥团(Data Clumps)
 *  基本类型偏执(Primitive Obsession)
 *  重复的switch(Repeated Switches)
 *  循环语句(Loops)
 *  冗赘的元素(Lazy Element)
 *  夸夸奇谈通用性(Speculative Generality)
 *  临时字段(Temporary Field)
 *  过长的消息链(Message Chains)
 *  中间人(Middle Man)
 *  内幕交易(Insider Trading)
 *  过大的类(Large Class)
 *  异曲同工的类(Alternative Classes with Different Interfaces)
 *  纯数据类(Data Class)
 *  被拒绝的遗赠(Refused Bequest)
 *  注释(Comments)

### 神秘命名 ###

整洁代码最重要的一环是好的名字，所以需要深思熟虑如何给函数、模块、变量和类命名，使它们能清晰地表明自己的功能和用法。

命名使编程中最难的两件事之一。因此改名可能是最常用的重构手法，包括改变函数声明(124)(用于给函数改名)、变量改名(137)、字段改名(244)等。

### 重复代码 ###

一旦有重复代码的存在，阅读这些重复的代码时就必须加倍仔细，留意其间细微的差异。如果要修改重复代码，必须找出所有的副本来修改。

最单纯的重复代码就是"同一个类的两个函数含有相同的表达式"。通过提炼函数(106)、或前后移动语句(223)等方法来提炼重复的代码。

### 过长函数 ###

每当感觉需要以注释来说明点什么的时候，就可以把需要说明的东西写进一个独立函数中，并以其用途命名。

如果函数内有大量的参数和临时变量，可能会对函数的提炼形成阻碍，或者在提炼出来的函数参数中并没有带来可读性的改善。这里可以运用以查询取代临时变量(178)来消除这些临时变量。引入参数对象(140)和保持对象完整(319)则可以将过长的参数列表变得更简洁一些。

如何确定该提炼哪一段代码呢？一个很好的技巧是：**寻找注释**。它们通常能指出代码用途和实现手法之间的语义距离。哪怕是只有一行代码，如果需要以注释说明，那也值得将它提炼到独立函数中。

对于庞大的switch语句，其中的每个分支都应该通过提炼函数编程独立的函数调用。如果有多个switch语句基于同一个条件进行分支选择，就应该使用以多态取代条件表达式。

至于循环，可以将循环和循环体内的代码提炼到一个独立的函数中。

### 过长参数列表 ###

过长的参数列表会让人产生迷惑。处理这种问题方式很多：

*  如果可以向某个参数发起查询而获得另一个参数的值，那么可以直接使用\*\*以查询取代参数(324)\*\*去掉第二个参数
 *  如果是从现有的数据结构中选取出很多项，可以使用\*\*保持对象完整(319)\*\*手法，直接传入原来的数据结构
 *  如果几项参数同时出现，可以用\*\*引入参数对象(140)\*\*将其合并成一个对象
 *  同样使用\*\*函数组合成类(144)\*\*也可以很有效地缩短参数列表

### 全局数据 ###

全局数据的问题在于，从代码库的任何一个角落都可以修改它，而且没有任何机制可以探测出到底哪段代码做出了修改。

首要的防御手段是**封装变量(132)**。把全局数据用一个函数包装起来，至少可以看到修改它的地方，并开始控制对它的访问。之后可以把它放在一个类或者模块中，只允许模块内的代码使用它，尽量控制作用域。

### 可变数据 ###

对数据的修改经常导致出乎意料的结果和难以发现的bug。需要采用一些手段来约束对数据的更新，降低风险。

*  可以用\*\*封装变量(132)\*\*确保所有数据更新操作都通过很少几个函数来进行，使其更容易监控和演进
 *  如果变量在不同时候被用于存储不同的东西，可以使用\*\*拆分变量(240)\*\*将其拆分为各自不同用途的变量
 *  把能够通过查询计算出来的变量\*\*以查询取代派生变量(248)\*\*方法处理
 *  使用\*\*函数组合成类(144)**或者**函数组合成变换(149)\*\*来限制需要对变量进行修改的代码量
 *  如果一个变量在其内部结构中包含了数据，通常最好不要直接修改其中的数据，而是用\*\*将引用对象改为值对象(252)\*\*令其直接替换整个数据结构

### 发散式变化 ###

一旦需要修改，只需要跳到系统的某一点，只在该处做修改。这是必须要做到的抽象，若因为修改一处代码同时牵连要修改多个函数，就会带来很严重的坏味道。

*  如果发生变化的两个方向自然地形成了先后次序，可以用\*\*拆分阶段(154)\*\*将两者分开，两者通过一个清晰的数据结构进行沟通

### 散弹式修改 ###

散弹式修改类似于发散式变化，如果遇到某种变化，都必须在许多不同的类内做出许多小修改，那么面临的坏味道就是散弹式修改。

面对这样的问题，一个常用的策略就是使用与内联(inline)相关的重构—如**内联函数(115)或是内联类(186)**—把本不该分散的逻辑拽回一处。完成内联之后，可能会闻到过长函数或者过大的类的味道，不过总可以用于提炼相关的重构手法将其拆解成更合理的小块。

### 依恋情结 ###

有时会发现，一个函数跟另一个模块中的函数或者数据交流格外频繁，远胜于在自己所处模块内部的交流。这种情况可以将这个函数跟这些数据待在一起，使用\*\*搬移函数(198)**把它移过去。如果函数只是一部分受影响，那可以先用**提炼函数(106)**把这一部分提炼到独立的函数中，再使用**搬移函数(198)\*\*移过去。

如果一个函数在几个模块中都用到，原则是：判断哪个模块拥有的此函数使用的数据最多，然后就把这个函数和那些数据摆在一起。

### 数据泥团 ###

往往在开发中，很多地方会看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。对于这些数据应该有属于它们自己的对象。可以采用\*\*提炼类(182)**将它们提炼到一个独立对象中，然后将注意力转移到函数签名上，运用**引入参数对象(140)**或**保持对象完整(319)\*\*为它瘦身。

有用的类被创建出阿里，大量的重复被消除，后续开发得以加速，原来的数据泥团就会在其范围能发挥更大的价值。

### 基本类型偏执 ###

### 重复的switch ###

任何switch语句都应该用\*\*以多态取代条件表达式(272)\*\*消除掉。甚至所有条件逻辑都应该用多态取代。

我们关注的是重复的switch：在不同的地方反复使用同样的switch逻辑(可能是以switch/case语句的形式，也可能是以连续的if/else语句的形式)。重复的switch的问题在于：每当想增加一个选择分支时，必须找到所有的switch，并逐一更新。

### 循环语句 ###

可以**用管道取代循环(231)**。管道操作(如filter和map)可以帮助更快地看清被处理的元素以及处理它们的动作。

### 冗赘的元素 ###

有时程序元素(如类和函数)能给代码增加结构，从而支持变化、促进复用或者哪怕只是提供更好地名字，但有时是不需要这层额外的结构。看起来略显累赘。

通常只需使用**内联函数(115)或内联类(186)**。如果类处于一个继承体系中，可以使用**折叠继承体系(380)**。

### 夸夸奇谈通用性 ###

存在一些方法或参数是用于在未来某一天会实现的，但暂时还未实现就写了进去，这会加深对系统的理解和维护。应该搬移掉。

如果抽象类没有太大作用，运用**折叠继承体系(380)**。不必须要的委托可运用\*\*内联函数(115)**和**内联类(186)**除掉。如果函数的某些参数未被用上，可以用**改变函数声明(124)**去掉这些参数。如果有并非真正需要、只是为不知远在何处的将来而塞进去的参数，应该用**改变函数声明(124)\*\*去掉。

### 临时字段 ###

有些类：其内部某个字段仅为某种特定情况而设，违背了通常认为对象在所有时候都需要它的所有字段的思维。

使用\*\*提炼类(182)**和**搬移函数(198)\*\*把所有和这些字段相关的代码都放到单独的类中统一管理。

### 过长的消息链 ###

用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后接着请求另一个对象…这就是消息链。容易造成的问题很明显，客户端代码将与查找过程中的导航结构紧密耦合。如果对象间的关系发生变化，客户端就必须做出修改。

使用**隐藏委托关系(189)**。先观察消息链最终得到的对象是用来干什么的，看能否\*\*提炼函数(106)**把使用该对象的代码提炼到一个独立的函数中，在运用**搬移函数(198)\*\*把这个函数推入消息链。

### 中间人 ###

对象的基本特征之一就是封装–对外部世界隐藏其内部细节。封装往往伴随着委托。而过度运用委托，如某个类的接口有一半的函数都委托给其他类。

使用**移除中间人(192)**，直接和真正负责的对象打交道。如果这些函数比较少，可以运用\*\*内联函数(399)\*\*把它们放进调用端。

### 内幕交易 ###

模块之间的数据交换会增加模块间的耦合。在实际情况里，一定的数据交换是不可避免的，但必须尽量减少这种情况，把交换放到明面上。

如果两个模块有共同的兴趣，可以尝试再新建一个模块，把这些公用的数据放在一个管理良好的地方；或者用**隐藏委托关系(189)**，把另一个模块变成两者的中介。

### 放大的类 ###

单个类做太多事情，往往会出现太多字段。重复代码也就不可避免。

可以运用提炼类(182)将几个变量一起提炼至新类内。提炼时应该选择类内彼此相关的变量，将它们放在一起。也可以观察一个大类的使用者，经常能找到如何拆分类的线索。看看使用者是否只用到这个类的所有功能的一个子类，每个这样的子类都可能拆分成一个独立的类。一旦识别出一个合适的功能子集，就试用**提炼类(182)**、\*\*提炼超类(375)**或者**以子类取代类型码(362)\*\*将其拆分出来。

### 异曲同工的类 ###

使用类的好处之一就是可以替换，但替换两个类必须保证接口一致性，才能替换。

可以通过\*\*改变函数声明(124)**将函数签名变得一致，必须保证两者之间的所有都一致才能替换。如果搬移过程造成了重复代码，可运用**提炼超类(375)\*\*补偿。

### 纯数据类 ###

### 被拒绝的遗赠 ###

子类应该继承超类的函数和数据。但如果继承的函数和数据有子类不需要的，意味着继承体系设计错误。

可以为这个子类新建一个兄弟类，再运用\*\*函数下移(359)**和**字段下移(361)\*\*把所有用不到的函数下推给那个兄弟。这样超类就只持有所有子类共享的东西。

### 注释 ###

注释常常被用于错误的使用，包括因为代码设计的很糟糕，才备注了常常的注释。借助注释可以找到本章先前提到的各种坏味道。找到会味道之后，首先应该以各种重构手法把坏味道去除。完成之后会发现：注释已经变得多余了，因为代码已经清楚的说明了一切。

只有在不知道该做什么，才是注释的良好运用时机。除了用来记述将来的打算之外，注释还可以用来标记并无十足把握的区域。可以记述下自己"为什么这么做"。帮助将来的修改者。