上个月，有个以前的同事问我：“你在的时候，为什么不把原来的系统都重做了，我们明明有实力啊”。

我说：“我们也做了很多事情嘛，系统稳定性、安全性、增加冗余、理清各模块职责、API 通讯机制的建立、内部分层的整理。”

他说：“对，但我还是想知道，你为什么不把系统重做了呢?”

于是我问：“我离职之后，后来似乎多投了不少人重做系统?结果怎么样呢?”

他说：“结果，结果就是做业务要同时操作三四套系统……”

就我所见，把原有系统 “推倒重来” 的喜好不只程序员有，使用者更有。拿我几年前的那份工作来说，刚入职老大们就来跟我讨论系统重做的打算：需要多少人，多少钱，多长时间，能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛：速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出 “敢叫日月 换新天” 的劲头，来个干脆的彻底解决。

这种心情可以理解，但在我任内 “重做系统” 一直没有被提上日程，整个技术团队所做的都是 “改良” 的工作，内容就像我上面说的：系统稳定性、安全性、增加冗余、理清各模块职责、API 通讯机制的建立、内部分层的整理。这个选择我有充分把握，而且在我看来，如果断然 “推倒重来”，我未必能比继任者做得更好，甚至可能更糟糕，因为 “推倒重来” 绝不是那么简单的事情。

众所周知，软件开发的难点之一就是控制复杂度。但是在不同的领域，复杂度有不同的表现。对于纯互联网业务，或者 IT 基础架构来说，其复杂度在于软件本身，架构的制定、类库的选择、编码的质量等等。对于其它 IT 系统——尤其是公司迅速成长，业务不断复杂化的 IT 系统——而言，其复杂度并不在于软件本身，安全、性能、负载的问题都套用现成的 IT 解决方案，真正的复杂度来自系统承载的业务本身，比如最简单的：系统里有哪些单据，各种单据承载什么信息，用在什么场景，这些单据是怎样流转的，各种单据存在怎样的约束关系，出现异常情况应当如何处理才能保证业务数据的一致性……这些问题没有准确而稳定的答案，IT 再怎样努力也是白搭。

对于已经能在线下规范运行的业务，或者是有经典解决方案的工作(比如财务、仓库管理)，这些知识都是现成的，可以直接拿来用。但对于新兴领域、新兴业务来说，往往不存在 “经典解决方案”。加上很多公司成长速度飞快，一开始并没有构筑好的 IT 基础(其实是业务架构基础)。典型的情况就是：业务概念混乱不清，业务逻辑层也是杂乱无章，很多系统里干脆把数据库当作业务逻辑层(这可不是说笑，因为数据库无法推脱责任了)。结果，混乱的业务逻辑依附于糟糕的 IT 系统，乱上加乱最终成了一锅粥。对 IT 来说，已有业务的问题层出不穷，每次出问题都需要花费大量精力，寻找蛛丝马迹来 “破案”;对业务来说，新增业务往往会影响到原有业务，但谁也不知道会不会影响，会如何影响。系统日渐庞大的另一面是内部日趋无序，复杂度和维护成本飞速增长，远远超过可控范围。

吊诡的是，许多人的解决办法不是针对问题的根本原因，评估业务复杂度、整理业务逻辑、整理业务关系，反而认为 “推倒重来”、新做一套系统就能解决。持这种观点的人，通常对系统与业务的关系也有误解。

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

如果要对基础不好的遗留系统做脱胎换骨的改造，我有几点经验可以参考：

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

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

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

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

如果你对改造遗留系统有自己的见解，或者在这个过程中有什么有意思的经历，欢迎留言给我。

最后推荐一本有意思的书。其实不管是软件开发还是社会变革，对于不喜欢的现状，大家往往喜欢来个 “干脆”、“彻底” 的解决方案，但真正成功的往往不是这些方案。在第二次世界大战结束时，世界上到底发生了哪些事情，遇到了哪些问题，又是怎样重建社会秩序的呢?广西师大《理想国》丛书第 9 册《零年：1945 现代世界诞生的时刻》，用翔实的文笔全面记录了 “终战” 之后的情景，许多画面相信会让读者大吃一惊——很多时候 “文明” 堪称被打回原形，“零年” 这个名字可谓名副其实。

编者按：面对遗留的老系统，人人都很不爽，都想推倒重来。但是要如何推倒重来呢?听听余晟的看法，本文首发于他的微信公众号余晟以为(yurii-says)

上个月，有个以前的同事问我：“你在的时候，为什么不把原来的系统都重做了，我们明明有实力啊”。

我说：“我们也做了很多事情嘛，系统稳定性、安全性、增加冗余、理清各模块职责、API 通讯机制的建立、内部分层的整理。”

他说：“对，但我还是想知道，你为什么不把系统重做了呢?”

于是我问：“我离职之后，后来似乎多投了不少人重做系统?结果怎么样呢?”

他说：“结果，结果就是做业务要同时操作三四套系统……”

就我所见，把原有系统 “推倒重来” 的喜好不只程序员有，使用者更有。拿我几年前的那份工作来说，刚入职老大们就来跟我讨论系统重做的打算：需要多少人，多少钱，多长时间，能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛：速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出 “敢叫日月 换新天” 的劲头，来个干脆的彻底解决。

这种心情可以理解，但在我任内 “重做系统” 一直没有被提上日程，整个技术团队所做的都是 “改良” 的工作，内容就像我上面说的：系统稳定性、安全性、增加冗余、理清各模块职责、API 通讯机制的建立、内部分层的整理。这个选择我有充分把握，而且在我看来，如果断然 “推倒重来”，我未必能比继任者做得更好，甚至可能更糟糕，因为 “推倒重来” 绝不是那么简单的事情。

众所周知，软件开发的难点之一就是控制复杂度。但是在不同的领域，复杂度有不同的表现。对于纯互联网业务，或者 IT 基础架构来说，其复杂度在于软件本身，架构的制定、类库的选择、编码的质量等等。对于其它 IT 系统——尤其是公司迅速成长，业务不断复杂化的 IT 系统——而言，其复杂度并不在于软件本身，安全、性能、负载的问题都套用现成的 IT 解决方案，真正的复杂度来自系统承载的业务本身，比如最简单的：系统里有哪些单据，各种单据承载什么信息，用在什么场景，这些单据是怎样流转的，各种单据存在怎样的约束关系，出现异常情况应当如何处理才能保证业务数据的一致性……这些问题没有准确而稳定的答案，IT 再怎样努力也是白搭。

对于已经能在线下规范运行的业务，或者是有经典解决方案的工作(比如财务、仓库管理)，这些知识都是现成的，可以直接拿来用。但对于新兴领域、新兴业务来说，往往不存在 “经典解决方案”。加上很多公司成长速度飞快，一开始并没有构筑好的 IT 基础(其实是业务架构基础)。典型的情况就是：业务概念混乱不清，业务逻辑层也是杂乱无章，很多系统里干脆把数据库当作业务逻辑层(这可不是说笑，因为数据库无法推脱责任了)。结果，混乱的业务逻辑依附于糟糕的 IT 系统，乱上加乱最终成了一锅粥。对 IT 来说，已有业务的问题层出不穷，每次出问题都需要花费大量精力，寻找蛛丝马迹来 “破案”;对业务来说，新增业务往往会影响到原有业务，但谁也不知道会不会影响，会如何影响。系统日渐庞大的另一面是内部日趋无序，复杂度和维护成本飞速增长，远远超过可控范围。

吊诡的是，许多人的解决办法不是针对问题的根本原因，评估业务复杂度、整理业务逻辑、整理业务关系，反而认为 “推倒重来”、新做一套系统就能解决。持这种观点的人，通常对系统与业务的关系也有误解。

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

如果要对基础不好的遗留系统做脱胎换骨的改造，我有几点经验可以参考：

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

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

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

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

如果你对改造遗留系统有自己的见解，或者在这个过程中有什么有意思的经历，欢迎留言给我。

来源：51CTO