面对旧系统的遗留问题，大家都很不爽，想推倒重来。但是你如何重新开始呢？听余生的意见。上个月，一个前同事问我：“你在的时候，为什么不重做原来的系统，我们明明有能力。”我说：“我们也做了很多事情，比如系统稳定、安全，增加冗余，明确各个模块的职责，建立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通信机制，组织内部层级”），同时通过过渡接口层与原有系统进行对接，原有模块在明确业务逻辑后，会根据需要裁剪出合适的接口，通过测试后逐个部分迁移。最终，新系统像拼图一样慢慢拼凑，直到最后一天成型，而不是平底搭建。在这个过程中，最关键的是找到合适的切入点，构建合适的接口或接口层。这些任务就像盖房子的脚手架。即使以后不用，中间也不能省略，一定要慎重对待。当然，这是一项具有挑战性的工作——我在数据库事务中遇到过跨数据库表连接查询。这种糟糕的设计严重阻碍了将单个数据库实例拆分为多个实例的进程。现在回想起来，就像一场噩梦。.如果你对改造遗留系统有自己的看法，或者在过程中有什么有趣的经历，欢迎给我留言。
