重构后的效率提升效果【续】一个方法几千行的程序是如何产生的？

被那个几千行的方法恶心后，就开始着手对代码进行重构。

 

由于重构前的代码基本是不可测的状态，所以此次基本上是推倒重来式的重构（只有部分业务逻辑代码重用）。

花了三天时间，把原有的业务逻辑梳理后，按照下面三个原则重新设计代码流程：

1：流程处理与各个业务的逻辑处理分开，实现流程与业务解耦
2：不同的业务规则代码分开，实现业务间解耦
3：同一业务规则的实现代码集中在一个实现类里，实现业务代码聚合

粘一个丑陋的类图：

 

 

 

如此设计的原因是：

1：虽然业务纷杂，五花八门，但大体上的业务处理流程是一样的，而且非常稳定（快两年了，流程仍然是最初的5大步骤）。将流程代码剥离之后，业务只需专注于每个处理步骤的实现，测试范围大大缩小。

 

2：由于在数据库中，一个业务表被多个业务复用，一个表字段在不同业务中代表含义不同的现象非常普遍。造成业务代码中重复的if.else.判断非常多。 代码可读性很差，而且难于维护（一个简单的业务变动要改20几个地方，漏掉几个也难以测试出来）。
     因此，把所有业务抽象了一个 abstract父类，所有具体业务都是该类的子类。 业务判断只在一个factory类里体现。业务变更的改动范围大大缩小。

 

3：同一业务的具体处理逻辑都在一个类里实现，实现同一个业务处理接口。由于接口封装了业务的变动，使流程处理的代码稳定下来。 增加新业务，只要实现该接口即可，大大减少了代码编写量。

 

 

重构后效果对比：（重构前，修改过一个简单的业务变更）

重构前：修改代码40行，花了1多小时。（改了10几处，大部分时间在看代码，眼都看花了）
重构后：只需改动2 行代码，不会超过5分钟。

 

重构前：测试花了2天，只覆盖变动的业务，改动代码涉及的其它业务没测试（都测一遍估计要半个月）。
重构后：0.5小时。

 

从此以后：谁再说改这个业务要2天，我打他屁股。

 

 

评论

3 楼 james_lover 2014-06-17  

代码结构随业务的变化而变化。
文章中的重构只适用于“业务与业务间相对独立”的情况。
如果“业务间耦合太紧” 就只能别想他法。
目前还没有遇见过一个复杂业务，跟另一个复杂业务间有复杂的关系的情况。

2 楼 a442579302 2014-06-17  

“打他屁股”。。。。。。先扔肥皂吗

1 楼 vinceall 2014-06-17  

亲身体会过，前期赶进度，switch不停的加case，后来抽象成事件驱动，每个event一个小类搞定~