重构代码总结

第2章 重构原则
重构
重构就是“代码整理”，最终使得程序开发效率更高，维护成本更低
如何效率更高，成本更低：代码结构清晰，耦合度低，封装合理，继承体系合理，改变性能
具体表现：添加新功能快速，修改快，且影响范围小

重构工作是无时不刻都可以进行的	

重构与重写：重构是代码重构前大部分功能正常工作；重写则是该代码负责的功能大部分不能正常工作

项目接近后期不应该进行重构工作

重构与设计
敏捷开发与传统开发一个不同点就是，代码就是设计的本身，摒弃了大量的设计说明，但并不意味着完全摒弃设计
个人觉得比较理想的一般情况：概要设计+重构，最终能通过代码能看到设计本身，但是几乎不可能的，除非工程很小，但是我们要朝着这个方向前进

第3章 代码bad smell
1.Duplicated code（重复代码）
2.Long method （过长函数）
3.Large class（过大类）
4.Long parameter list (过长参数列表)
5.divergent change（发散式变化）
某个类经常因为不同原因而在不同的方向上变化，这就导致了这个类不纯粹，结构不单一，书本上例子：“如果新加入一个数据库，我必须修改这三个函数；如果新出现一种金融工具，我必须修改这四个函数”
6.Shotgun surgery（霰弹式变化）
每遇到变化，就需要在不同的类里进行许多小修改
7.Feature envy（依恋情结）
某个函数对某个类的兴趣高于自身所在的类
8.Data clumps（数据泥团）
如果多个经常出现在一起的数据字段或参数列表
9.Primitive obsession（基本类型偏执）
10.Switch statements（switch语句）
大量相似的switch语句
11.Parallel inheritance hierarchies（平行继承体系）
增加某个类的子类，必须也为另一个类增加相应的子类
12.Lazy class（冗赘类）
无用或几乎无用的东西
13.speculative generality（夸夸其谈未来性）
为未来作的预估，但目前缺没有用到的
14.Temporary field（迷惑字段）
为做某件事特别而设的，如某类实例变量仅为某种特定情况而设，其他用处一点也没有
15.Message chains（过长消息链）
A对象请求B对象，B对象请求C对象，C对象请求D对象，最终调用D的某个方法
16.Middle man（中间人）
A通过B知道C的某个东西，B不做，直接依托C来完成，这种“委托”不能过多，例如某类的接口有一半的函数都委托给其他类，就是一种过度的middle man bad smell


17.Inappropriate intimacy（狎昵关系）
两个类耦合度过高，如A类很多事情都要依赖B类去完成；或者继承，子类对超类的了解过深，往往是超类所不想的
18.Alternative classes with different interface（异曲同工的类）
名字不同（类或函数或其他），缺做的事情差不多一样
19.Incomplete library class（不完美的类库）
类库的设计不能完美地预估以后的需要
20.Data class（纯粹的数据类）
对于该类应该好好封装起来，不得随意由外部变动内部数据
21.Refused bequest（被拒绝的遗赠）
继承往往会带来很多子类不期望的内容，子类或许只要其中的几样，现有A类超类，B类子类继承与A，A不想要B的很多其他东西，做法是：新建一个子类C，将A类抽象成抽象类，不要的东西推给C类，这样A类就持有的仅是BC类共有的少量内容
22.Comments
有注释的地方表示可以抽离出来，如果抽离出来还需要注释，再抽离，直到觉得不需要注释；注释最佳用处：不知道该做什么；没有把握的地方；或者意图告诉其他人，这一块代码为了什么而做什么