本文好多知识来源于《重构》
为何重构:
改进设计
易于理解
避免补丁循环
更快的编写新代码
何时重构:
经常,随时
添加功能时
修改bug时
代码review之后
何时不重构:
代码太混乱,不如重写
项目的最后期限
重构原则
小步进行
重构不改变代码的外观行为
重构时清楚自己是在重构,写新代码时,清楚自己在写新代码
经典的坏味道
违反单一原则
单一原则
类:只代表一个角色
方法:只做一件事
接口:只代表某一种方面的抽象。保持最少知识原则
字段:只代表一种意义
过长的方法
判定:
左右过长的判定:单个屏幕不能显示出左右的全部信息
上下过长的判定:单个屏幕不能完全显示完整个方法的上下
修改:
提取子方法
拆分方法
过大的类
修改:提取类
重复
判定:
相同或相似的代码多次出现
修改:
提取类
提取方法
提取父类
名不达意
判定:
方法、类、字段的名字并不能恰当的表达应有的含义
更多请参考
rename
拆分方法
提取类
命名更多请参考:http://blog.csdn.net/time_hunter/article/details/13984049
不符合逻辑
代码的实现不符合逻辑常理,往往存在潜在的问题
代码颗粒失衡
不同粒度的代码调用不应该放在同一级别。(处理细节的代码,不应该与具有概括性的代码放在一起)
方法中横向过深的嵌套
横向过多的条件嵌套,并不合适阅读
修改:
可以酌情使用卫语句简化实现,横向嵌套->纵向延伸
字段过长的生命周期
public class Director { private Builder builder; public Director(Builder b) { builder = b; } public void construct(){ builder.buildFloor(); builder.buildHousetop(); builder.buildWall(); } }
上面的代码,builder作为成员变量,但是只是在一个方法中用到,可以修改为下面的代码public class Director { public void construct(Builder builder){ builder.buildFloor(); builder.buildHousetop(); builder.buildWall(); } }
复杂的逻辑运算表达式 || 难懂的代码
封装某些表达式为恰当名字的方法
给运算表达式提取成有意义的局部变量
使用反向判断原则简化逻辑
过长的匿名内部类的使用
封装成一个方法,过长的匿名内部类会破坏代码的可读性
模块间过多的耦合
使用门面模式,对外提供统一的访问入口
不同于原有代码的风格
如 : JavaBean的字段访问是通过get set还是public访问,本有争议,使用的时候参考原有的实现方法