代码的坏味道
本章讲到重构何时需要开始、何时需要结束。
我们通过对代码的阅读， 就能够感知到整个代码架构里 是否有脏东西出现。
1.神秘命名：不能清晰的表明自己的功能和用法，给人造成迷惑。好的名字能节省未来用在猜谜上的时间。如果想不出一个好名字，说明背后很可能潜藏着更深的设计问题。
2.重复代码：同一个类的两个函数含有相同的表达式 。
危害：如果要修改重复代码，你必须找出所有的副本来修改。
3.过长函数：代码太多的函数，难以阅读和维护。每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途(而非实现手法)命名。
4.过长参数列表：函数参数太多，代码臃肿不易理解。可以使用查询取代参数去掉传入参数，或者使用保持对象完整手法，直接传入对象。
5.全局数据：从代码库的任何一个角落都可以修改它，而且没有任何机制可以探测出到底哪段代码做出了修改。
首要的防御手段是封装变量(132)，并开始控制对它的访问。最好将这个函数(及其封装的数据)搬移到一个类或模块中，只允许模块内的代码使用它，从而尽量控制其作用域 。
6.可变数据：在一处更新数据，却没有意识到软件中的另一处期望着完全不同的数据。可以用封装变量(132)来确保所有数据更新操作都通过很少几个函数来进行，使其更容易监控和演进 。
7.发散式变化：一个类因为不同的原因而需要频繁修改。拆分模块，界定上下文边界。每当要对某个上下文做修改时，我们只需要理解这个上下文，而不必操心另一个。
8.霰弹式修改：需要修改的代码散布四处，你不但很难找到它们，也很容易错过某个重要的修改。使用搬移函数(198)和搬移字段(207)把所有需要修改的代码放进同一个模块里 。
9.依恋情结：一个函数跟另一个模块中的函数或者数据交流格外频繁，远胜于在自己所处模块内部的交流。
10.数据泥团：成群结队的数据应该拥有属于他们自己的对象。
11.基本类型偏执：有含义的类型被当作普通类型使用。应当运用对象取代基本类型，将原本单独存在的数据值替换成对象。
12.重复的switch：switch语句都应该用以多态取代条件表达式(272)消除掉 。
13.循环语句：管道操作(如filter和map)可以帮助我们更快地看清被处理的元素以及处理它们的动作。
14.冗赘的元素：拆分的粒度有可能导致类的功能过于小。
15.夸夸其谈通用性：不必要的抽象类和参数。
16.临时字段：其内部某个字段仅为某种特定情况而设。
让函数可读、 让架构可解析、不要让代码与工程被过度设计。