没人想碰的遗留系统改造

上周在南京河西的产业园跟做了十五年Java开发的老周喝茶，他刚从一个项目里撤出来，整个人蔫的。

为啥？他接了个遗留系统改造的活，干了三个月，差点把头发薅没了。

你面对的根本不是代码，是一地鸡毛的历史

他接手的系统是2012年给本地国企做的供应链管理平台，当年写核心模块的开发早在2016年就离职了，连最初的需求文档都凑不齐。翻遍客户的档案柜，找出来的还是Word2003格式的初稿，最后三页全是乱码，问当时的对接人，人家说那几页是讲用户权限的，后来上线的时候砍了，根本没实现。

最绝的是仓储成本计算的核心模块。没人知道当初为啥要写三层嵌套的if判断，连对应的测试用例都没留下。老周第一次读这段代码的时候，盯着屏幕坐了俩小时，没敢动一行。

很多人刚接触这类项目，第一反应就是要重构、要上微服务、要把旧代码全换掉。

扯淡。

麻烦在于，这个系统现在每天要处理三百多笔出入库单据，一旦停服超过两小时，仓库的人就得拿纸质单据记账，月底对账能对到整层楼的人加班到凌晨。你根本没机会停下来把所有逻辑摸透。

老周说他最崩溃的一次，只是把一个用户备注字段的长度从20个字符改到50个，结果整个成本模块直接崩了。查了半天才发现，有个藏在工具类里的冷门方法，把这个字段的值直接拼进了数据库查询语句，之前跑了八年都没出问题，因为从来没人往这个字段里输过超过20个字符的内容。

最容易栽的跟头，就是想一步到位

我见过太多公司做遗留系统改造，一开始就喊着要三年完成全部上云，把所有单体应用拆成微服务，全部替换成最新的技术栈。钱砸了两百万请咨询公司出方案，干了半年，连核心的订单模块都没拆完。

为啥？你拆代码的时候，业务部门还在不停提新需求啊。仓库要加临期商品预警，财务要改最新的税率计算规则，这些需求你不能不接，接了，拆代码的进度就得往后拖。

这事没那么玄。我见过最稳的一个改造项目，根本没搞什么运动式的重构。人家先在旧系统外面套了一层API网关，把所有请求先拦下来，能转接到旧系统的就先转，新开发的功能直接走新的云服务。每次只拆一个模块，拆完就切对应路由，留一周的观察期，出问题就一键切回旧系统，半分不影响业务跑。

说白了，遗留系统改造从来不是技术问题，是风险控制问题。你要是上来就想把旧系统全砸了重写，大概率要栽。

去年有个创业公司的CTO跟我吐槽，说他们当年脑子一热，把跑了五年的用户系统全部重写，上线那天直接崩了十二个小时，服务器日志刷了几十万条，最后还是靠旧系统的备份导回数据才救回来。那次故障之后，他整整三个月没敢在公司提“重构”两个字。

对了，老周说他上次去客户那边对接，发现仓库管理员的电脑上还插着个2015年买的U盘，里面存着系统第一次上线时的操作手册，封皮都磨掉一半了。

别等系统崩了才想起动手

很多公司对遗留系统的态度很统一：能跑就别动。动了就要担责任，不动的话，哪怕系统慢一点，至少不会出大问题。

但代价是什么？现在刚毕业的开发，根本看不懂当年写的Struts2代码，连配置文件从哪找都不知道。系统每次出故障，就得找当年写代码的老开发，人家现在都在别的公司当技术总监了，你得按小时付费，一次故障排查就要好几万。更别说那些早年写的代码根本没做输入校验，随便爬个页面就能摸到数据库的权限，真被人拖了库，损失就不是几十万的事了。

老周最后是怎么收尾的？他没急着拆整个系统，就是把最容易出问题的成本计算模块单独抽出来，写了个新的计算服务，把旧系统里的对应逻辑全部复刻了一遍，跑了三个月的双轨对比，两边算出来的仓储成本分毫不差，才慢慢把流量切过去。剩下的模块，他跟客户说每个季度拆一个，不着急。

客户一开始还嫌慢，直到旧数据库的官方版本停止维护，他们提前把数据平滑迁移到新数据库里，没出任何问题，客户才反应过来，慢有慢的道理。

上周跟老周再喝茶，他说那个项目已经跑了快一年了，除了一次运营商网络波动导致的短暂中断，没出过大问题。他说很多人对遗留系统改造有误解，觉得要炫技，要用上最潮的技术栈。

其实根本不是。

你要做的，就是让每天靠这个系统吃饭的人，别因为你的改造丢了饭碗。

就够了。