业务系统升级改造——从小木船到航空母舰

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

并且，技术升级其实并不难。首先，大多数状况下，技术方案都是比较通用的：你也用SpringCloud，我也用SpringCloud，我俩的方案即便不是如出一辙，相去也不过毫厘之间。其次，技术升级通常会采用开发人员比较了解和掌握的技术，这样设计、实施起来会比较驾轻就熟。所以，这类升级这里很少说。

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

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

不知道算幸运仍是算不幸