找出那些代码里的坏味道吧——《重构》笔记（一）-CSDN博客

写在前面

重构起源于smalltalk，发扬于java和C#，它们都有成熟的重构工具。有一种说法是，《重构》和设计模式是java行业的圣经。我个人觉得，重构就像修缮忒休斯之船一样，只是我们是将船上的木板全部替换成了钢板。一个程序员如果看自己一年前写的代码而没有重构的念头，那么这个程序员可能这一年没有什么进步，当然也可能这块代码已经不需要重构了，但我想这种概率挺低的。

因为各种原因，没有人能在框架设计一开始就能套用设计模式写好，所以我们的代码需要不断的重构。Gof的设计模式就是重构的目标。但是重构也是必须有理论准备的，必须系统化的进行，否则可能引入不可察觉的错误，风险更大。

本文记录的重点只在于指出代码里的坏味道，如果在你的代码中“闻到”了这些坏味道就说明这块的代码可能需要重构了，至于怎么重构，书中有一套系统的方法，请期待后续的文章。

最后，希望重构能变成像空气和水一样普通的技术。

代码的坏味道有如厨房的油污，开始时不会觉得有多大的影响，但时间长了就会累积成“恶心”又难以“清除”的污渍。我们需要保持每天的清扫，而不是定期的“大扫除”。上面的“味道”就是一点一点的“油星”溅在“厨房”里，看到它们就顺手擦掉吧！

一、重构原则

1.重构的定义

重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
关于重构需要强调的两点：
- 重构的目的是使软件更容易被理解和修改。
- 重构不会改变软件可观察的行为——重构之后软件功能一如以往。

2.重构的目标

进行重构之后，我们希望我们的程序能达到以下几点目标：
- 容易阅读
- 所有逻辑都只在唯一地点指定
- 新的改动不会危及现有行为
- 尽可能简单表达条件逻辑

3.何时不该重构

现有代码根本不能正常运行时，应该重写，而不应重构。
如果项目已近最后期限，你也应该避免重构。

二、代码的坏味道

Duplicate Code（重复代码）
- 如果你在一个以上的地点看到相同的程序结构，那么可以肯定，设法将它们合二为一，程序会变得更好。
Long Method（过长函数）
- 拥有短函数的对象会活的比较好，比较长。
- 我们遵循这样一条原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。
- 条件表达式和循环常常也是提炼的信号。
Large Class（过大的类）
- 如果想利用单个类做太多事情，其内往往就会出现太多实例变量。
- 和“太多实例变量”一样，类内如果有太多代码，也是代码重复、混乱并最终走向死亡的源头。最简单的解决方案是把多余的东西消弭于类内部。
- 这里有个技巧：先确定客户端如何使用它们（指“太多的实例变量”），然后运用Extract Interface为每一种使用方式提炼出一个接口。这或许可以帮助你看清楚如何分解这个类。
Long Parameter List（过长参数列）
- 如果你手上没有所需的东西，总可以叫另一个对象给你。因此，有了对象，你就不必把函数需要的所有东西都以参数传递给它了，只需传给它足够的、让函数能从中获得自己需要的东西就行了。
Divergent Change（发散式变化）
- 指的是，如果一个类中引入一个新的变化，需要修改多个函数，则需要考虑将这个类一分为二。
- 针对某一外界变化的所有相应修改，都只应该发生在单一类中，而这个新类内的所有内容都应该反应此变化。
Shotgun Surgery（霰弹式修改）
- Divergent Change是指“一个类受多种变化的影响”，Shotgun Surgery则是指“一种变化引发多个类相应的修改”。这两种情况下你都会希望整理代码，使“外界变化”与“需要修改的类”趋于一一对应。
Feature Envy（依恋情结）
- 函数对某个类的兴趣高过对自己所处类的兴趣。
- 判断哪个类拥有最多被此函数使用的数据，然后就把这个函数和那些数据摆在一起。
- 最根本的原则是：将总是一起变化的东西放在一块儿。数据和引用这些数据的行为总是一起变化的，但也有例外。如果例外出现，我们就搬移那些行为，保持变化值在一地发生。
Data Clumps（数据泥团）
- 你常常可以在很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据真应该拥有属于它们自己的对象。
- 一个好的评判办法是：删除众多数据中的一项。这么做，其他数据有没有因而失去意义？如果它们不再有意义，这就是个明确信号：你应该为它们产生一个新对象。
Primitive Obsession（基本类型偏执）
- 对象的一个极大的价值在于：它们模糊（甚至打破）了横亘于基本类型和体积较大的类之间的界限。你可以轻松编写一些与语言内置（基本）类型无异的小型类。
- 对象技术的新手通常不愿意在小任务上运用小对象——像是结合数值和币种的money类、由一个起始值和一个结束值组成的range类、电话号码或邮政编码等的特殊字符串。你可以运用Replace Data Value With Object将原来单独存在的数据值替换为对象，从而走出传统的洞窟，进入炙手可热的对象世界。
Switch Statements（switch惊悚现身）
- 面向对象程序的一个最明显特征就是：少用switch（或case）语句。
- 大多数时候，一看到switch语句，你就应该考虑以多态来替换它。
- 如果你只是在单一函数中有些选择事例，且并不想改动它们，那么多态就有点杀鸡用牛刀了。
Parallel Inheritance Hierarchies（平行继承体系）
- 每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类。
- 消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
Lazy Class（冗赘类）
- 你所创建的每一个类，都得有人去理解它，维护它，这些工作都是要花钱的，如果一个类的所得不值其身价，它就应该消失。
Speculative Generality（夸夸其谈未来性）
- 当有人说“嗷，我想我们总有一天需要做这事”，并因而企图以各种各样的钩子和特殊情况来处理一些非必要的事情，这种坏味道就出现了。
- 如果所有装置都会被用到，那就值得那么做；如果用不到，就不值得。用不上的装置只会挡你的路，所以，把它搬开吧。
Temporary Field（令人迷惑的暂时字段）
- 有时你会看到这的对象：其内某个实例变量仅为某个特定情况而设。
- 请使用Extract Class给这个可怜的孤儿创造一个家，然后把所有和这个变量相关的代码都放进这个新家。
Message Chains（过度耦合的消息链）
- 如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象……这就是消息链。
- 先观察消息链最终得到的对象是用来干什么的，看看能否以Extract Method把使用该对象的代码提炼到一个独立函数中，再运用Move Method把这个函数推入消息链。如果这条链上的某个对象有多位客户打算航行此航线的剩余部分，就加一个函数来做这件事。
Middle Man（中间人）
- 人们可能过度运用委托。你也许会看到某个类接口有一半的函数都委托给其他类，这样就是过度运用。这时应该使用Remove Middle Man，直接和真正负责的对象打交道。
Inappropriate Intimacy（狎昵关系）
- 有时你会看到两个类过于亲密，花费太多时间去探究彼此的private成分。
- 就像古代恋人一样，过分狎昵的类必须拆散。你可以采用Move Method和Move Field帮它们划清界线，从而减少狎昵行径。
- 继承往往造成过度亲密，因为子类对超类的了解总是超过后者的主观愿望。
Alternative Classes With Different Interfaces（异曲同工的类）
- 如果两个函数做同一件事，却有着不同的签名。请运用Rename Method根据它们的用途重新命名。但这往往不够，请反复运用Move Method将某些行为移入类，直到两者的协议一致为止。
Incomplete Library Class（不完美的类库）
- 麻烦的是库往往构造得不够好，而且往往不可能让我们修改其中的类使它完成我们希望完成的工作。
- 如果你只想修改类库的一两个函数，可以运用Introduce Foreign Method；如果想要添加一大堆额外行为，就得运用Introduce Local Extension。
Data Class（纯稚的数据类）
- 所谓Data Class是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。
- Data Class就行小孩子，作为一个起点很好，但若要让它们像成熟的对象那样参与整个系统的工作，它们就必须承担一定责任。
Refused Bequest（被拒绝的遗赠）
- 如果子类复用了超类的行为（实现），却又不愿意支持超类的接口，Refused Bequest的坏味道就会变得浓烈。拒绝继承超类的实现，这一点我们不介意；但如果拒绝继承超类的接口，我们不以为然。不过即使你不愿意继承接口，也不要胡乱修改继承体系，应该运用Replace Inheritance With Delegation来达到目的。
Comments（过多的注释）
- 常常会有这样的情况：你看到一段代码有着长长的注释，然后发现，这些注释之所以存在乃是因为代码很糟糕。
- 如果你不知道该做什么，这才是注释的良好运用时机。