代码的坏味道

神秘命名（Mysterious Name）

说白了就是命名不规范，无意义，字段、变量、函数、类等

重复代码（Duplicated Code）

过长函数（Long Function）

作者一直在不遗余力的宣传小函数的简洁优美

过长参数列表（Long Parameter List）

过长参数令人迷惑，不利于函数的使用和可持续性维护

全局数据（Global Data）

第一版里没有这个，没太理解

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

可变数据（Mutable Data）

如果要更新一个数据结构，就返回一份新的数据副本，旧的数据保持不变。

发散式变化（Divergent Change）

一旦需要修改，我们希望能够跳到系统的某一点，只在该处做修改。如果不能做到这点，你就嗅出两种紧密相关的刺鼻味道中的一种了

如果某个类经常因为不同的原因在不同的方向上发生变化，Divergent Change就出现了

说白了就是一个类承担了两种以上不同类型的指责

霰弹式修改（Shotgun Surgery）

如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是Shotgun Surgery。如果需要修改的代码散布四处，你不但很难找到它们，也很容易忘记某个重要的修改。

依恋情结（Feature Envy）

一个函数跟另一个模块中的函数或者数据交流格外频繁，远胜于在自己所处模块内部的交流

数据泥团（Data Clumps）

两个类中相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据真应该拥有属于它们自己的对象。

基本类型偏执（Primitive Obsession）

很多程序员不愿意创建对自己问题域有用的基本类型。

如果你有一组总是同时出现的基本类型数据，就是数据泥团的征兆

重复的switch（Repeated Switch）

第二版与第一版有不同，不再那么强烈

以多态替换switch

循环语句（Loops）

这也是第一版没有的

以管道操作取代循环

冗余的元素（Lazy Element）

元素：类、函数等

夸夸其谈通用性（Speculative Generality）

一些不必要的过度设计

临时字段（Temporary Field）

某个字段为某种特殊情况而设

过长消息链（Message Chains）

一个用户向一个对象请求另一个对象，再向后者请求另一个对象...

中间人（Middle Man）

过度使用委托，比如一个类的接口有一半的函数都委托给其他类

内幕交易（Insider Trading）

模块之间的数据交换应该放在明面上来

过大的类（Large Class）

单个类想做的事情太多

异曲同工的类（Alternative Classes with Different Interfaces）

纯数据类（Data Class）

大概就类似于我们的Entity类，持保留意见

被拒绝的遗赠（Refused Bequest）

如果子类复用了超类的行为（实现），却不愿意支持超类的接口

注释（Comments）

当你感觉需要撰写注释的时候，请先尝试重构，试着让所有注释变得多余

好的代码应该自解释