转自如此 http://www.cnblogs.com/matchcolor/tag/%E9%87%8D%E6%9E%84/
综述：编码过程中不应该有的21中习惯和现象
每一种“味道”都会由对应的表现形式，遍历和避开每一种形式，就会离“优美”越近。
1. 重复代码
代码重复往往来自于“copy-and-paste”的编程风格，是Refactoring的主要目标之一。
2. 冗长的方法
冗长的方法体是传统结构化的“遗毒”。一个方法应当具有自我独立的意图，不要把几个意图放在一起。
3. “大类”
“大类”就是把太多的责任交给一个类，需要使用到---One Class One Responsibility规则。
4. 分散改变
一个类里面的内容变化率不同。面向对象的抽象就是把相对不变的和相对变化的相隔离，把问题变化的一方面和另一方面相隔离；这使得相对不变的可以重用，问题变化的每个方面都可以单独重用。而相异变化的共存使得重用变得非常困难。
5. 散弹式修改
对一个地方的改变涉及到其他许多地方的相关修改，这些变化内容的状态和行为通常应当放在同一个类中。
6. 依恋情节
如果一个类的方法频繁用getXxx()存取其他类的状态进行计算，那么需要考虑把该行为移到涉及最多数据的那个类中去。
7. 数据泥团
若方法出现很多个参数，并且这些参数通常成群出现，应该考虑将这些数据建立成一个独立的对象。
8. 基本数据类型“偏执”
面向对象新手通常习惯使用几个原始类型的数据来表示一个概念。好的习惯是扩充语言所能提供的原始类型，如果有一组应该总是被放在一起的字段，可以运用“提炼类”的方式；如果在参数列表中考到基本数据类型，可以尝试引入参数对象；如果发现有数组参数，可以对象取代数组。
9. Switch语句 惊悚现身
面向对象程序的一个最明显特征就是：少用switch语句。从本质上说，switch语句的问题在于重复。如果要为它添加一个新的case字句，就必须找到所有的switch语句并修改它们。面向对象中的多态概念能够很好解决以上问题。
10. 平行继承体系
每当为某个类增加一个子类，必须相应地为另一个类增加一个子类；如果发现某个继承体系的类名前缀和另一个继承体系的类名前缀完全相同，则这就是平行继承体系。
11. 冗余类
如果某些子类没有足够的工作，应该消除它们；或者折叠继承体系。类的维护需要额外的开销。
12. 夸夸其谈未来性
一个类实现了从未用到的功能和通用性。
13. 令人迷惑的临时变量
类中某些变量仅为特定你情况而定；这些代码不容易让人理解；在变量未被使用的情况下猜测当初设置的目的，会是一件很不愉快的事情；使用提炼类的方法给这些变量创建一个家，把所有和这些变量相关的代码都放到这个家中，还可以使用“引入Null对象”，在变量不合法的情况下创建一个null对象，从而避免写条件代码。
14. 过渡耦合的消息链
如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象……这就是消息链。实际代码中你看到的可能是一长串 getXxx() 或一长串临时变量。采取这种方式，意味客户代码将与查找过程中的导航紧密耦合。一旦对象间关系发生任何变化，客户端就不得不做出相应的修改。
15. 过多的中间人
对象的基本特征之一就是封装：对外部世界隐藏其内部细节。封装往往伴随委托。比如说你问你主管是否有时间参加一个会议，他就把这个消息“委托”给他的记事簿，然后才能回答你。你没必要知道这位主管到底使用传统记事簿或电子记事簿或秘书来记录自己的约会。
16. 类的亲密关系
有时候你会看到2个类过于亲密，花费太多时间起探究彼此的private成分。
17. 异曲同工的类
做相同的事情的方法却又不同的函数签名。
18. 不完整的类库
复用常被视为对象的终极目的。不过复用的意义常被高估：大多数对象只要够用就好。但是无可否认，许多编程技术都建立在程序库的基础上。
19. 纯稚的数据类
所谓的Data Class是指：它们拥有一些字段，以及用于访问这些字段的函数，除此之外一无长物。这样的类只是不会说话的数据容器，它们几乎一定被其他类过分细琐的操控着。
20. 被拒绝的遗赠
子类应该继承超类的函数和数据。但如果它们不想或不需要继承，又该这么办呢？它们得到所有礼物，却只从中挑选几样来玩。
21. 过多的注释
如果经常感觉需要写很多的代码注释，才能够理解代码；如果这种感觉过多，表示需要重构代码了。一旦重构了代码，会发现：注释已经变得多余了，因为代码已经清楚地说明了一切。如果你需要注释来解释一块代码做了说明，试试Extract Method （提炼函数）；如果函数已经提炼出来，但还是需要注释来解释其行为，试试 Rename Method （函数改名）；如果你需要注释说明某些系统的需求规格，试试 Introduce Assertion （引入断言）。