面这段代码，尽管是特意为举例而写的，要是真实遇到这种代码，想必大家都“一言难尽”吧。大家多多少少都有一些坏味道的代码的“印象”，坏味道的代码总有一些共性：
Duplicated Code（重复代码） Long Method（过长函数） Large Class （过大的类） Long Parameter List（过长参数列） Temporary Field（令人迷惑的暂时字段） Shotgun Surgery（霰弹式修改）：一种变化引发多个类相应修改 ......
那坏味道的代码是怎样形成的呢？
上一个写这段代码的程序员经验、水平不足，或写代码时不够用心； 产品经理提出的奇葩需求导致写了很多hack代码； 某一个模块业务太复杂，需求变更的次数太多，经手的程序员太多。 ......
对坏味道的代码有一个大概的了解后，或许读者心中有一个疑问：代码的好坏有没有一些量化的标准去评判呢？答案是肯定的。 接下来，通过了解圈复杂度去衡量我们写的代码。然而当代码的坏味道已经“弥漫”到处都是了，这时我们应该了解一下重构。代码到了我们手里，不能继续“发散”坏味道，这时应该了解如何编写 clean code。此外，我们还应该掌握一些编码原则及设计模式，这样才能做到有的放矢。
