对于其它IT系统——尤其是公司迅速成长，业务不断复杂化的IT系统——而言，其复杂度并不在于软件本身，安全、性能、负载的问题都套用现成的IT解决方案，真正的复杂度来自系统承载的业务本身，比如最简单的：系统里有哪些单据，各种单据承载什么信息，用在什么场景，这些单据是怎样流转的，各种单据存在怎样的约束关系，出现异常情况应当如何处理才能保证业务数据的一致性……这些问题没有准确而稳定的答案，IT再怎样努力也是白搭。

对于已经能在线下规范运行的业务，或者是有经典解决方案的工作（比如财务、仓库管理），这些知识都是现成的，可以直接拿来用。但对于新兴领域、新兴业务来说，往往不存在“经典解决方案”。加上很多公司成长速度飞快，一开始并没有构筑好的IT基础（其实是业务架构基础）。

典型的情况就是：业务概念混乱不清，业务逻辑层也是杂乱无章，很多系统里干脆把数据库当作业务逻辑层（这可不是说笑，因为数据库无法推脱责任了）。结果，混乱的业务逻辑依附于糟糕的IT系统，乱上加乱最终成了一锅粥。对IT来说，已有业务的问题层出不穷，每次出问题都需要花费大量精力，寻找蛛丝马迹来“破案”；对业务来说，新增业务往往会影响到原有业务，但谁也不知道会不会影响，会如何影响。系统日渐庞大的另一面是内部日趋无序，复杂度和维护成本飞速增长，远远超过可控范围。

科泰北大青鸟java培训技术专家表示：许多人的解决办法不是针对问题的根本原因，评估业务复杂度、整理业务逻辑、整理业务关系，反而认为“推倒重来”、新做一套系统就能解决。持这种观点的人，通常对系统与业务的关系也有误解。

对希望“推倒重来”的人来说，系统和业务的关系，有点像车辆对人员：一辆车我开了一段时间觉得不好，就想换一辆车来开，这是很自然的。但是在信息化深入工作各个角落的今天，系统和业务的关系远不是“车辆对人员”那么疏远，而更像“心脏起搏器对人”，或者“人造骨骼与肌肉”的关系，已经如胶似漆缠在了一起，系统对业务的支持越多越广（暂时不论质量），双方纠缠得也就越紧密。更换心脏起搏器或者人造骨骼的难度，远远比换车的难度要大，所以需要慎重考虑，不能单纯因为心脏起搏器“不那么好”就轻率决定更换。对系统来说，也是如此。

如果要对基础不好的遗留系统做脱胎换骨的改造，科泰北大青鸟java培训技术专家有几点经验可以参考：

第一，一定要有非常优秀的业务人员和开发人员。

对业务人员来说，不但要熟悉自己手头的操作，还必须明白操作背后的逻辑，并且需要超越本职工作，能从全局角度来思考自己的业务（有时甚至要让自己操作更复杂，来提高系统安全性等收益），这样才能真正把握住业务的复杂度。对开发人员来说，要能够完整理解领域知识，同时必须有高超的编程能力来应对遗留代码，敢于出手而不是畏缩不前，谨慎出手而不是贸然行动——如果原有系统开发人员的技术能力可以打30分，全新开发系统的技术要求是60分，那么要成功改造遗留系统的技术人员，往往需要有80以上的分数才能胜任。

第二，“推倒重来”往往不如“逐步改良”。

所谓“逐步改良”，指的是大家先通过讨论确认未来系统的设计蓝图，然后需要开发用于过渡的接口层。于是，新开发的模块一定要严格按照新的规范开发（这也就是我说的“理清各模块职责、API通讯机制的建立、内部分层的整理”），同时通过过渡的接口层与原有系统对接，原有的模块则在理清业务逻辑的情况下，按需切出合适的接口，逐部分在测试通过的情况下进行迁移。最终新的系统是像拼图一样慢慢拼出来到最后一天才成型的，而不是平底盖楼造起来的。在这个过程中，最关键的是找到合适的切入点，搭建出合适的接口或者接口层。这些工作就像盖房子的脚手架，哪怕之后不会用到，中途也不能省略，还必须仔细对待。当然，这是一个考验人的工作——我曾经遇到过数据库事务里跨库连表的查询，这个糟糕的设计严重阻碍了单数据库实例拆分成多实例的进展，回想起来真是如噩梦一般。