现在组里接的新需求，一半都要先给跑了18年的COBOL系统”磕头”——哦不对，是兼容。
没人真的想碰这堆老代码。
没人真的想碰的老代码
很多人对遗留系统的第一印象是”技术垃圾”，觉得是该被扫进历史的过时产物。真不是。
那些跑了十几年的系统，背后是无数业务在一次次大促、故障、监管检查里趟出来的隐形规则，没有写在正式的需求文档里，全藏在代码的犄角旮旯里。比如某段写在支付模块里的规则，凌晨2点到4点所有跨行转账要走旧通道，原因是2010年运营商的专线只有那个时段不堵，现在专线换了三茬，没人敢删这行代码。删了？万一半夜出几十万的异常交易，谁担？
文档？不存在的。
最早写这个模块的工程师2015年就移民加拿大了，微信都加不上，剩下的注释全是”此处特殊处理，勿动”，连为啥特殊都没写。上次有个做零售的团队想把老库存系统拆成微服务，光梳理里面藏着的300多个业务分支规则，就花了9个月——比整个微服务开发的时间还长一倍。
很多人觉得改造遗留系统，就是把旧技术换成新技术，像换手机似的简单。真上手才知道，这跟给跑了20年的老汽车换发动机没区别，你得先搞清楚每根线路是接在哪的，不然换完了说不定哪天开着开着方向盘就掉了。
改造不是拆积木
最常见的坑，就是上来就全量替换。
说白了就是觉得老系统烂得没救，全扔了重写，拍胸脯说半年就能上线新系统。去年有个连锁零售客户就踩了这个坑，把跑了10年的ERP全换成了最新的云版本，上线第一周，门店上报的库存数差了12%。原因说出来都可笑：老系统里有个规则，临期3天的商品要自动从可售库存里扣，新系统的逻辑是临期7天才扣，光这一个规则的差异，就让门店多退了两百多万的临期食品。
谁的锅？
没人愿意担。当初做需求调研的时候，没人去门店跟着理货员蹲一周，光找老系统的运维问，人家说”大概是这么个逻辑”，就拍板定了方案。
还有个更蠢的坑，为了改造而改造。
现在张嘴就是上云、微服务、云原生，不管老系统的问题根源是什么，硬要把单体拆成二十几个微服务。拆完才发现，原来的老系统响应慢，根本不是架构的问题，是早年的订单表没建索引，每次查询全表扫，你拆完微服务，跨服务调用的网络延迟比原来单体的查询时间还长，用户骂得比之前更凶。
很多时候遗留系统的问题，根本不是技术架构过时，是没人愿意花时间理清楚它到底在干什么。
真正划算的改造是什么样
这事没那么玄。
别上来就喊着”全面替换””技术升级”的口号，先把老系统的家底摸清楚。哪些功能是天天有人用的，哪些功能是三年都没人点过一次的，哪些规则是藏在代码里没写进文档的，先把这些摸明白，再谈怎么改。
老周他们现在组里的做法就很实在，不赶进度，也不对外吹什么改造成果。每次接新需求，就把对应的老系统模块慢慢替换，拆下来一个，就把老系统对应的入口关掉，出问题了随时切回去，没有心理负担。就这么不紧不慢跑了两年，现在老系统的代码量已经少了60%，也没出过一次影响业务的大故障。
他们甚至专门建了个文档库，把挖出来的隐形规则一条条记下来，后面标清楚来源——”2012年双11大促临时调整，无正式发文””2018年监管要求增加的校验逻辑，后因规则修改忘记删除”。这些东西，你在任何公开的技术手册里都找不到，全是靠翻历史工单、找退休老员工聊天、甚至去查早年的项目报销记录才挖出来的。
说穿了，遗留系统改造从来都不是什么酷炫的技术项目。没有闪闪发光的发布会，没有对外能吹的技术名词，就是一帮人蹲在机房，对着满屏的黑底代码，跟十几年前的工程师留的烂摊子打交道。改完了用户根本感觉不到变化。
没变化就是最好的变化。
别信那些说”三个月搞定全量遗留系统改造”的供应商。他们要么没碰过真正跑了十年以上的老系统，要么就是打算做完收钱就跑，留个烂摊子给你擦屁股。
这活没捷径。