重构改善既有代码的设计的第三章—— 代码的坏味道
书中也提到，重构是不存在精确衡量标准的。根据作者的观点，没有任何规则比得上一个见识广博者的直觉。当然我们也必须培养出自己的判断力。
下面根据书中给出的规则结合自己工作经验，做个总结：
如果遇到以下情况，则意味着可以着手进行重构优化工作啦。
1. 重复代码(Duplicated Code)
涉及到重复代码的问题，在实际的开发过程中，稍有常识的开发者一般都会对其展开优化。根据重复代码的范围，对其方法or类进行抽象，提炼代码。
2. 函数过长(Long Method)
我们都知道: 程序越长越难理解。所以我们在开发过程中应该积极地分解函数。
通常需要遵循这样一条规则：每当感觉需要以注释来说明点什么的时候，就可以考虑将需要说明的东西写入到一个独立的函数中，并以其用途命名。我们要意识到：函数的关键在于函数的功能而非长度。
这里我们需要合理地分解函数，避免引入过多参数，否则我们则需要定义类来消除过长的参数列表。
如何确定该提炼哪一段代码呢？
书中给我们的技巧：
- 寻找注释。它们通常能指出代码用途和实现手法之间的语意距离。我们应该使函数名称能很好的起到见名知意的效果。
- 条件表达式和循环也是很好的提炼信号。
3. 类内容过大(Large Class)
一个类如果拥有太多代码，则意味着我们考虑对类进行优化，也可能意味着从架构上做出改变。比如：我们从MVC —> MVP框架的演进。
4. 参数列表过长(Long Parameter List)
全剧变量是邪恶的东西
关于参数列表过长，估计在开发过程我们自己也受不了，尤其是不知道参数对应关系的时候更是抓耳挠腮，令人抓狂。
5. 复杂的修改操作
书中提到的：
- 发散式变化(Divergent Change)
- 霰弹式修改(Shotgun Surgery)
- 依恋情结(Feature Envy)
从本质上来讲，就是让我们将需要变化的部分尽量集中在一处。从而避免漏改的发生。
6. switch语句
作者认为：面向对象的程序的一个最明显特征就是：少用switch语句。因为switch语句意味着重复。看到swtich语句，则应该考虑多态来替换它。
这个在类层次的话，肯定应该考虑多态。
7. 未来代码
编程中可没有特南克斯 23333…
这里其实挺有意思的，我们在开发的过程中，总是处于长远的考虑，在项目中引入或者写下暂时用不到的代码。实际上往往用不到的…（PS：实践出真知）
听取作者的建议——用不上的装置只会挡路，删掉吧
8. 慎用继承
继承的局限性：
- 继承往往造成过度亲密，因为子类对超类的了解总是超过后者的主观意愿。
- 子类不想or不需要继承超类的一部分内容。
另外，复用的意义经常被高估——大多数对象只要够用就好。
所以我们应该考虑：使用代理替代继承
9. 多余注释
在我们拿到别人的代码时，总是希望看到对面的注释，但是我们的目的是要更好的理解代码的含义，而不是看注释。
当感觉需要撰写注释时，请先尝试重构，试着将所有的注释变得多余。
按照作者的观点，注释主要用来：
- 记述将来的打算；
- 标记不确定的区域；
对此，I can not agree more…，因为我们的目的是理解代码的含义
刚入侯门之时，读这本书的感受就是——XJB扯…
现在读来，犹如清风拂面…
代码就想酒，如果感觉不到书中的观点，那就请你再品,again and again…