代码坏味道

最近在做项目的代码重构和治理，根据《重构》的定义：

在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。

良好的代码设计对与后续维护、改动的作用是不可忽视的。差劲的代码重构，几乎等同于重写。

1.Duplicated Code(重复的代码)

坏味道的首当其冲是重复的代码Duplicated Code。假设你在一个以上的地点看到同样的程序结构，那么当可肯定：设法将它们合而为一，程序会变得更好。

最单纯的Duplicated Code就是［同一个class内的两个方法含有同样表达式(expression)］。

2.Long Method(过长方法)

我们遵循这样一条原则：每当感觉须要写注释来说明代码的时候。我们就把须要说明的东西写进一个独立的方法中，并以其意图(而非实现手法)命名。

3.Large Class(过大的类)

说明这个类做太多事情。其内往往就会出现太多instance变量。

一旦如此。Duplicated Code也就接踵而至了。

4.Long Parameter List(过长參数列)

5.Divergent Change(发散式修改)

我们希望软件可以更easy被改动——毕竟软件再怎么说本来就该是[软]的。

一旦须要改动，我们希望可以找到系统的某一点，仅仅在该处做改动。

Divergent Change是指[一个class受多种变化的影响]

6.Shotgun Surgery(霰弹式改动)

Shotgun Surgery类似Divergent Change。但恰恰相反。假设每遇到某种变化，你都必须在很多不同的class内做出很多小改动以响应之。你所面临的坏味道就是Shotgun Surgery。假设须要改动的代码散布四处。你不但非常难找到它们。也非常easy忘记某个重要的改动。

Shotgun Surgery是指[一种变化引发多个classes对应改动]。

7.Feature Envy(依恋情结)

我们会看到某个方法为了计算某值，从还有一个对象那儿调用差点儿半打的取值方法。

最根本的原则是：将总是一起变化的东西放在一块儿。［数据］和[引用这些数据]的行为总是一起变化的。

8.Data Clumps(数据泥团)

数据项就像小孩子：喜欢成群结队地待在一块儿。你经常能够在非常多地方看到同样的三或四个数据项：两个classes内的同样字段、很多方法签名式中的同样參数。这些[总是绑在一起出现的数据]真应该放进属于它们自己的对象中。

9.Primitive Obsession(基本类型偏执)

大多数编程环境都有两种数据：结构类型让你将数据组织成有意义的形式；基本类型则是构成结构型别的积木块。

10.Switch Statements(switch惊悚现身)

面向对象程序的一个最明显特征就是：少用switch(或case)语句。

11.Parallel Inheritance Hierarchies(平等继承体系)

Parallel Inheritance Hierarchies事实上是Shotgun Surgery的特殊情况。在这样的情况下。每当你为某个class添加一个subclass，必须也为其它已实现的兄弟class对应添加一个subclass。

12.Lazy Class(冗赘类)

你所创建的每个class，都得有人去理解它、维护它，这些工作都是要花钱的。

假设一个class的所得不值其身份。它就应该消失。

13.Speculative Generality(夸夸其谈未来性)

这个令我们十分敏感的坏味道，命名者是Brian Foote。当有人说“噢，我想我们总有一天须要做这事”并因而企图以各式各样的挂勾和特殊情况来处理一些非必要的事情，这样的坏味道就出现了。

14.Temporary Field(令人迷惑的临时字段)

有时你会看到这种对象：其内某个instance 变量仅为某种特定情势而设。这种代码让人不易理解，由于你通常觉得对象在全部时候都须要它的全部变量。在变量未被使用的情况下推測当初其设置目的，会让你发疯。

15.Message Chains(过度耦合的消息链)

假设你看到用户向一个对象索求还有一个对象，然后再向后者索求还有一个对象，然后再索求还有一个对象……这就是Message Chain。实际代码中你看到的可能是一长串getThis()或一长串暂时变量。採取这样的方式，意味客户将与查找过程中的航行结构紧密耦合。

16.Middle Man(中间转手人)

人们可能过度运用delegation。你或许会看到某个class接口有一半的方法都托付给其他class，这样就可能是过度运用。

17.Inappropriate Intimacy(狎昵关系)

有时候你会看到两个classes过于亲热，花费太多时间去探究彼此的private成分。假设这发生在两个[人]之间。我们不必做卫道之士；但对于 classes，我们希望它们严守清规。

继承往往造成过度亲热，由于subclass对superclass的了解总是超过superclass的主观愿望。假设你认为该让这个孩子独自生活了，请运用Replace Inheritance with Delegation让它离开继承体系。

18.Alternative Classes with Different Interfaces(异曲同工的类)

假设两个方法做同一件事，却有着不同的签名式。

19.Incomplete Library Class(不完美的程序类库)

20.Data Class(纯稚的数据类)

所谓Data Class是指：它们拥有一些字段，以及用于訪问这些字段的方法，除此之外一无长物。

21.Refused Bequest(被拒绝的遗赠)

Subclasses应该继承superclass的方法和数据。但假设它们不想或不须要继承，又该怎么办呢？它们得到全部礼物。却仅仅从中挑选几样来玩！

按传统说法，这就意味继承体系设计错误。

22.Comments(过多的注释)

别操心，我们并非说你不该写注释。

从嗅觉上说，Comments不是一种坏味道；其实它们还是一种香味呢。

我们之所以要在这里提到Comments，由于人们常把它当作除臭剂来使用。

经常会有这种情况：你看到一段代码有着长长的注释。然后发现，这些注释之所以存在乃是由于代码非常糟糕。这种情况的发生次数之多。实在令人惊讶。

Comments能够带我们找到本章先前提到的各种坏味道。