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

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

由于重构前的代码基本是不可测的状态，所以此次基本上是推倒重来式的重构（只有部分业务逻辑代码重用）。花了三天时间，把原有的业务逻辑梳理后，按照下面三个原则重新设计代码流程：

粘一个丑陋的类图：

如此设计的原因是：

虽然业务纷杂，五花八门，但大体上的业务处理流程是一样的，而且非常稳定（快两年了，流程仍然是最初的5大步骤）。将流程代码剥离之后，业务只需专注于每个处理步骤的实现，测试范围大大缩小。
由于在数据库中，一个业务表被多个业务复用，一个表字段在不同业务中代表含义不同的现象非常普遍。造成业务代码中重复的if.else.判断非常多。代码可读性很差，而且难于维护（一个简单的业务变动要改20几个地方，漏掉几个也难以测试出来）。因此，把所有业务抽象了一个 abstract父类，所有具体业务都是该类的子类。业务判断只在一个factory类里体现。业务变更的改动范围大大缩小。
同一业务的具体处理逻辑都在一个类里实现，实现同一个业务处理接口。由于接口封装了业务的变动，使流程处理的代码稳定下来。增加新业务，只要实现该接口即可，大大减少了代码编写量。

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

重构前：修改代码40行，花了1多小时。（改了10几处，大部分时间在看代码，眼都看花了）
重构后：只需改动2 行代码，不会超过5分钟。
 
重构前：测试花了2天，只覆盖变动的业务，改动代码涉及的其它业务没测试（都测一遍估计要半个月）。
重构后：0.5小时。

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