“重构，一言以蔽之，就是在不改变外部行为的前提下，有条不紊地改善代码”。《重构——改善既有代码的设计》一书已经很充分的介绍了如何做重构。如果我们只需要对一小段流程、一小部分代码做重构，这本书已经提供了非常实用的工具。不过，如果我们要对整个系统做一个全面的升级改造，书中的技巧就有些“一叶障目不见泰山”了。

而且，技术升级其实并不难。首先，大多数情况下，技术方案都是比较通用的：你也用SpringCloud，我也用SpringCloud，我俩的方案即使不是一模一样，相去也不过毫厘之间。其次，技术升级一般会采用开发人员比较了解和掌握的技术，这样设计、实施起来会比较得心应手。因此，这类升级这里不多说。

但是业务升级却恰恰相反。首先，与通用的技术方案不同，业务逻辑就如孙悟空一般，同样的业务可以变化出七十二种不同的方案来。例如，同是账务系统的记账业务，就可能有单边账、双边账、会计科目账等不同的记录方法，账务系统A的设计方案与账务系统B的设计方案也许就是水火不容的。其次，开发人员对业务的了解和掌握程度，既不像对技术那样深入，也不像产品或业务人员那样熟悉。因此，由开发人员来升级业务系统，颇有点强人所难了。

尽管更加困难，业务升级有时比技术升级更加迫在眉睫。很多业务系统从立项伊始就伴随着业务的“野蛮生长”，因而不得不采取疯狂堆代码、先上线再说这样饮鸩止渴的策略。遵循这种策略开发出的代码，很快就会陷入高度冗余、高度耦合的泥潭中，并由此导致业务逻辑不清晰、改一个需求动一万行代码、天天加班需求还是搞不完、好不容易上线了却bug不断等种种问题。雪上加霜的是，由于陷入其中无法自拔，开发人员既没有精力去提高自身技术水平，也很难忙里偷闲来对系统做技术升级。何况，应对这些问题时，技术升级并不是对症的良方：由于对整个系统的理解上一叶障目不见泰山、或者改造时牵一发而动全身，技术升级往往只能得到局部最优解而非全局最优解。就更不要说技术升级有时还要依赖业务升级的成果了。

不知道算幸运还是算不幸