1个好的程序员顶10个普通的程序员，程序员之间的差异很大，这是大家的共识，这个差异应该主要表现在设计思想和方法上面。清晰的代码结构和优雅的设计方法在软件开发中的重要性不用多说。成功的原因各不相同，失败的原因却总是相似的。如果一段代码是不稳定或者有一些潜在问题的，那么代码往往会包含一些明显的痕迹。正如食物要腐坏之前，经常会发出一些异味一样。我们管这些痕迹叫做“代码坏味道”。下面主要介绍代码的坏味道，开发中要特别注意这样的代码，他们往往是失败的软件的开始。

可度量的味道

过长的方法

1. 过长的方法往往难以理解，特别是在理解别人的代码的时候，发现这样的方法，往往有抵触心理，大多数人都不喜欢读太长的方法。
2. 过长的方法不易维护，一个方法里面的逻辑过多，在后期维护、扩展的时候可能会出现各种问题，复杂条件式和循环体常常是提炼的信号。

大类

1. 类太大往往是因为做了太多事情，有些事情不是自己该做的，可能是抽象不够
2. 类太大通常会出现太多的实例变量

过多的参数

1. 方法的参数过多不易理解和使用，考虑是否可用对方法进行拆分或使用默认参数

过多的注释

1. 注释太多让人厌烦，就像演讲一样，尽说废话，没人想听，应该言简意赅，让人一听就明白。
2. 当你感觉需要注释，请先尝试重构，试着让所有的注释都变得多余，好的代码本身就应该是自注释的。

不必要的复杂性

过度设计

1. 超出需求过多的设计往往是过度设计，对某种变化的应对，而这种变化没有发生，也许永远都不会发生。

重复

重复代码

1. 往往由于设计的问题导致多处存在相似或相同的一段代码，考虑将这些代码提取到一个方法中。

异曲同工的类

1. 如果出现多个类在做同样或相似的事情，考虑将这些类进行提炼融合，保证代码的简洁性。

条件逻辑

switch语句太长

1. switch语句太长容易导致重复的代码，考虑使用模式或多态来替换。

基本类型太多

1. 软件中，基本类型被过度使用。在某些场合下，应该使用一些小的类来代替这些基本类型。

纯稚的数据类

1. 这些类拥有一些字段，并提供了对应的Getter和Setter方法，除此以外一无所有。这些类只是一些不会说话的数据容器， 而且它们必定会被其他类过分琐细地操作。

数据泥团

1. 反复出现的一组参数，有关联的多个数组换成类

令人迷惑的暂时值域

1. 有时候你会看到一个对象的实例变量仅为某些特定的场合而设。这样的代码将导致难以理解，因为你期望一个对象需要它所有的变量。很多情况下，这些值域应该不属于此class ，而应该单独的提取成新的类。

被拒绝的遗赠

1. 子类继承父类的方法和数据，但是它们只需要使用其中的一部分，考虑用代理替代继承关系。

亲密关系

1. 有时候，类之间的关系变得非常亲密，并且需要花费大量时间来探究彼此之间的私有成分。考虑对他们进行拆散合并。

冗赘类

1. 不要创建没有价值的类

职责

发散式变化

1. 如果某个类经常因为不同的原因在不同的方向上发生变化就会产生发散式变化。也就是说，一个类拥有多个引起它发生变化的原因。

霰弹式修改

1. 霰弹式修改与发散式变化类似，却又存在相反的一面。每次进行某种修改时，你都必须对多个不同的类进行很多对应的小修改。

平行继承体系

1. 平行继承体系是霰弹式修改的一个特例。在这种情况下，当你为某个类增加一个子类时，你不得不为另一个类也相应增加一个子类。你也许能够识别到这种味道，因为一个继承体系中类的类名前缀与另一个体系中的类名前缀一样。

库类

不完善的程序库类

1. 库类在使用时一定要小心，特别是在我们不知道一个库是否完整时。

参考

1. 《重构——改善既有代码的设计》
2. 刘伟技术博客