注释
症状
注释太多
成因
因为代码违反直觉，所以需要注释说明。这也往往以为着代码的臭味。最好的注释是给类或方法起个好名字。
治疗
通过抽变量的方式给一个复杂的表达式命名；
通过抽方法的方式给一段代码命名；
收益
消除注释但是不降低代码的可读性正是重构追求的目标。
重复代码
症状
成因
无意的重复发明轮子和故意的复制现有代码
治疗
同一个类中，抽方法
如果两个兄弟类有重复的代码：
- 上提方法及属性到基类中
- 如果在构造方法中，则上提构造方法体
- 如果有部分相同，部分不同，则考虑采用模板方法模式
如果两个无关的类有相同的代码：
- 抽基类
- 抽类，委托
如果多个if 分支做相同的事情，则合并条件为一个方法
收益
简洁代码
什么时候不用：
有时，代码去重可能会降低代码的直观性
Lazy Class
症状
可有可无的类
成因
一个类被重构成了很少的代码；
一个类被设计为为了满足将来的需求；
治疗
inline class;
裁剪继承体系；
收益
什么时候应忽略
一个类作为一个设计的占位符，需要进一步完善。
数据类
症状
一个类只有数据，以及getter/setter, 需要依赖其他类操作它。
成因
一个常见的错误是，认为entity 不能做为数据传输对象。
治疗
收益
数据要和对数据操作的代码靠在一起。
死代码
症状
废弃的代码
成因
业务变化，只添加却不做清理；
从不可能满足的某个条件语句
治疗
使用工具检查代码
收益
简洁代码
Speculative Generality
症状
为了“考虑全面”而产生的代码，包括类，字段，方法及参数，却从未使用
成因
考虑全面
治疗
收益
229
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
