重构-读书与实践的体验

本文好多知识来源于《重构》

为何重构：

改进设计

易于理解

避免补丁循环

更快的编写新代码

何时重构：

经常，随时

添加功能时

修改bug时

代码review之后

何时不重构：

代码太混乱，不如重写

项目的最后期限

重构原则

小步进行

重构不改变代码的外观行为

重构时清楚自己是在重构，写新代码时，清楚自己在写新代码

经典的坏味道

违反单一原则

单一原则

类：只代表一个角色

方法：只做一件事

接口：只代表某一种方面的抽象。保持最少知识原则

字段：只代表一种意义

过长的方法

判定：

左右过长的判定：单个屏幕不能显示出左右的全部信息

上下过长的判定：单个屏幕不能完全显示完整个方法的上下

修改：

提取子方法

拆分方法

过大的类

修改：提取类

重复

判定：

相同或相似的代码多次出现

修改：

提取类

提取方法

提取父类

名不达意

判定：

方法、类、字段的名字并不能恰当的表达应有的含义

更多请参考

rename

拆分方法

提取类

命名更多请参考:http://blog.youkuaiyun.com/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访问，本有争议，使用的时候参考原有的实现方法