一、代码竟会有“气味”
食物在腐烂之际，会散发出异味，提醒人食物已经坏掉了，需要处理。同样，如果代码中某处出现了问题，也会有一些症状。这些症状，被称之为“代码异味”（Code smell，也译作“代码味道”）。与食物腐败发出的味道不同的是，代码异味并非真正的气味，而是一种“暗示”，暗示我们代码可能有问题，提示程序员需要对项目设计进行更进一步的查看。
代码异味一词最初是由Kent Beck在帮助Martin Fowler在编写《重构：改善既有代码的设计》一书时创造的。Martin Fowler对代码异味的定义是：代码异味是一种表象，它通常对应于系统中更深层次的问题。代码异味的产生原因跟厨师的“清洗过程中故意保留”不一样，它更多地并非刻意为之，创造者也未必“品尝”过自己所写的代码，它更多地是由于设计缺陷或不良编码习惯而导致的不良代码症状。
这种异味也并非来自一种有据可查的标准，更多的是来自程序员的直觉。尤其是经验丰富和知识渊博的程序员，他们无需思考，只要通过查看代码或一段设计就可以立马对这个代码质量产生这种“感觉”，能对代码设计的优劣有一个大致的判断。这有点类似我们英语学到一定程度后，即便不能完全看懂文章，但凭借语感也能选出正确答案。
二、 代码异味的影响
对于代码异味的出现我们其实无需过度紧张，因为在整个程序中代码异味是无处不在的。
一般情况下，有“异味”的代码也依旧能运行得很好。只是倘若重视不够，没有适当地维护或改进代码，代码质量就会下降，系统也会开始变得难以维护和扩展，同时也会增加技术债务。这就像做出有异味的九转大肠的的小胖厨师，在前期准备中对评委的建议置若罔闻，一意孤行，做出来的菜连自己都难以下咽。
所以团队应尽可能地做有质量的代码，减少甚至避免这些问题，产生高效益的成果。
三、 如何辨别代码异味
代码是否存在代码异味，通常是靠程序员的主观判断，但由于语言、开发者、开发理论的不同，对代码异味的判断也会存在差异。
所以要想更精准地识别代码异味，获得更高的代码质量，程序员需要大量的实践和经验。不过，前辈们总结的经验也可以让我们少走一些弯路。Martin Fowler在《重构：改善既有代码的设计》一书中，列举了最常见的24种代码异味，可以帮助我们轻松识别，便于处理和改善它们：
1) 过大的类（Large Class）
一个类包含许多字段、方法或者代码行，并逐渐变得臃肿。
2) 数据泥团（Data Clumps）
代码的不同部分包含了相同的变量组，且这些数据总是绑在一起出现。
3) 过长参数列表（Long Parameter List）
指一个方法的参数超过了三个或四个。出现这种情况一般是将几种类型的算法合并到一个方法之后。
4) 基本类型偏执（Primitive Obsession）
创建一个原始字段比创建一个全新的类要容易得多，所以对于具有意义的业务概念如钱、坐标、范围等，很多程序员不愿意进行建模，而是使用基本数据类型进行表示，进而导致代码内聚性差、可读性差。
5) 神秘命名（Mysterious Name）
在编程中，命名是一件非常恼人的事情。一些可能只有自己看懂的命名，无疑加大了代码可读性的难度，有时甚至自己也会忘记这些命名的含义。
6) 重复代码（Duplicated Code）
这几乎是最常见的异味。当多个程序员同时处理同一程序的不同部分时，通常会发生这种情况。
7) 过长的函数（Long Function）
根据Martin Fowler的经验，通常活得最长、最好的程序，其中的函数都比较短。函数越长，就越难理解。
8) 全局数据（Global Data）
这是一个非常可怕且刺鼻的异味代码。因为从代码库的任何一个角落都可以修改它，而且没有任何机制可以探测出到底是哪段代码做出了修改。全局数据造成一次又一次的诡异Bug，让我们很难找出出错的代码。
9) 可变数据（Mutable Data）
如果可变数据的变量的作用域越大, 越容易出现问题。变量是可以更改的，但我们可能不知道是哪里改变了它。
10) 发散式变化（Divergent Change）
是指一个类受到多种变化的影响。
11) 霰弹式修改（Shotgun Surgery）
是指一种变化引发多个类相应修改。
12) 依恋情结（Feature Envy）
一个类使用另一个类的内部字段和方法的数据多于它自己的数据。
13) 重复的Switch（Repeated Switch）
在不同的地方反复使用switch逻辑。这带来的问题就是当我们想要增加一个选择分支时，就必须找到所有的switch，并逐一更新。
14) 循环语句（Loops）
在编程语言中，循环一直是程序设计的核心要素。在《重构》中，Martin Fowler认为它是一种代码异味，因为他们觉得如今的循环已经有点过时了。他们提出“以管道取代循环”，这样可以帮助我们更快看清被处理的元素以及处理它们的动作。
15) 冗赘的元素（Lazy Element）
这是几乎无用的组件。我们在设计代码时有时为了未来的功能设计出“预备”代码，但实际上从未实现；又或者这个类本来有用但随着重构，越来越小，最后只剩下一个函数。无论哪种，它们都是冗赘无用的。
16) 推测的通用性（Speculative Generality）
是指为了“以防万一”，支持预期的未来功能，但这些功能并未被实现，这些类、方法、字段或参数也从未被使用，结果导致代码变得难以理解和支持。
17) 临时字段（Temporary Field）
创建临时字段以用于需要大量输入的算法。但这些字段仅在算法中使用，其余时间不使用。
18) 过长的消息链（Message Chains）
当客户端请求另一个对象，该对象又请求另一个对象，依此类推时，就会出现过长的消息链。这些链意味着客户端依赖于类结构的导航。一旦发生更改，客户端也要跟着修改。
19) 中间人（Middle Man）
指一个类只执行一个动作，但将工作委托给另一个类，这种委托属于过度委托。该类也可能只是一个空壳，只负责委托且只有一件事。
20) 内幕交易（Insider Trading）
指模块之间大量地交换数据，增加模块之间的耦合。
21) 异曲同工的类（Alternative Classes with Different Interface）
是指两个类执行了相同的功能但具有不同的方法名称。
22) 纯数据类（Data Class）
指包含字段和访问它们的粗略方法（getter 和 setter）的类。这些只是其他类使用的数据容器。这些类不包含任何附加功能，并且不能独立操作它们拥有的数据。
23) 被拒绝的遗赠（Refused Bequest）
指如果子类复用了超类的行为，但又不愿意支持超类的接口的情况。
24) 注释（Comments）
程序员将其作为一种“除臭剂”使用情况下的行为。比如：一段代码有着长长的注释，但这段长注释的存在是因为代码很糟糕。
四、 如何对代码“除臭”
1）重构
上述代码异味没有优先级一说，所以对于程序员而言，只能依靠直觉和经验去决定是否需要重构。
重构，一言以蔽之，就是在不改变外部行为的前提下，有条不紊地改善代码。是实现敏捷性的最重要的技术因素之一。是程序员根据已识别出的气味然后将代码分成更小的部分的过程，再决定要么删除它们，要么用更好的代码替换它们，如此循环重复这个过程，直到异味消失，这样可能会提高代码质量并让代码变得更具简单性、灵活性和可理解性。
2）使用代码检测工具
识别和消除代码异味是一个令人厌烦且不确定的过程，而且也不可能手动查找到和删除掉所有异味，尤其是面对一个有着上千行异味的代码的时候。所以使用一些代码检测工具可以辅助我们进行快速大量地审查，帮助我们节约时间来做更为重要的工作，比如能专注于代码高层面的设计原则问题。
好了，关于代码异味的知识，算是讲了个清楚，那么让我们相约下一次代码评审吧！
标签：重构,故意,代码,Fowler,程序员,字段,异味 From： https://www.cnblogs.com/zentao/p/17187371.html