类型

神秘命名
重复代码
过长函数
过长参数列表
全局数据：全局数据的问题在于，从代码库的任何一个角落都可以修改它，而且没有任何机制可以探测出到底哪段代码做出了修改。一次又一次，全局数据造成了一些诡异的 BUG，而问题的根源却在遥远的别处。
可变数据：对数据的修改经常导致出乎意料的结果和难以发现的 BUG。我在一处更新数据，却没有意识到软件中的另一处期望着完全不同的数据。
发散式变化：模块经常因为不同的原因在不同的方向上发生变化。
散弹式修改：每遇到某种变化，你都必须在许多不同的类内做出许多小修改。
依恋情结：所谓模块化，就是力求将代码分出区域，最大化区域内部的交互、最小化跨区域的交互。但有时你会发现，一个函数跟另一个模块中的函数或者数据交流格外频繁，远胜于在自己所处模块内部的交流。
数据泥团：你经常在很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。
基本类型偏执：很多程序员不愿意创建对自己的问题域有用的基本类型，如钱、坐标、范围等。
重复的 switch：在不同的地方反复使用相同的 switch 逻辑。问题在于：每当你想增加一个选择分支时，必须找到所有的 switch，并逐一更新。
循环语句：我们发现，管道操作（如 filter 和 map）可以帮助我们更快地看清被处理的元素一级处理它们的动作。
冗余的元素
夸夸其谈通用性：函数或类的唯一用户是测试用例。
临时字段：有时你会看到这样的类：其内部某个字段仅为某种特定情况而定。这样的代码让人不理解，因为你通常认为对象在所有时候都需要它的所有字段。在字段未被使用的情况下猜测当初设置它的目的，会让你发疯。
过长的消息链
中间人：过度运用委托。
内幕交易：软件开发者喜欢在模块之间筑起高墙，极其反感在模块之间大量交换数据，因为这会增加模块间的耦合。在实际情况里，一定的数据交换不可避免，但我们必须尽量减少这种情况，并把这种交换都放到明面上来。
过大的类
异曲同工的类
纯数据类：所谓纯数据类是指：他们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。纯数据类常常意味着行为被放在了错误的地方。也就是说，只要把处理数据的行为从客户端搬移到纯数据类里来，就能使情况大为改观。
被拒绝的遗赠：拒绝继承超类的实现，我们不介意：但如果拒绝支持超类的接口，这就难以接受了。
注释：当你感觉需要纂写注释时，请先尝试重构，试着让所有注释都变得多余。