上周帮一家做制造的朋友看他们的工单系统，打开后台代码仓库的瞬间，我盯着屏幕愣了半分钟。提交记录最后一行停在2016年。写代码的那个工程师，现在已经在北欧做户外向导了。
没人接盘。
你顺着提交记录翻，能看到从2010年开始，前后换了七波开发，每波人留的注释都带着上一波人的吐槽，有人在2015年的代码旁边写”上一个人写的这逻辑是脑子抽了吗，我不敢改”，到2016年最后一次提交，留的注释是”我走了，你们加油”。我手边放着的冰可乐都温了，还没缓过神。真的，没人愿意给十年前的代码擦屁股，但活总得有人干。
你根本不知道你在改什么
麻烦在于，老系统里的注释，很多是当年的开发喝多了写的，什么”这里别改，改了就炸””2013年财务大姐要求加的特殊逻辑，没有文档”。80%的老系统故障，从来不是核心代码崩了，是没人知道的边角特殊逻辑被碰了。
我见过最离谱的一个系统，为了兼容2008年买的一台针式打印机，代码里硬编码了打印机的控制指令，后来行政统一换了新的激光打印机，整个出库流程卡了三天，没人记得这段代码存在。你说这叫技术债？这是埋在代码里的定时炸弹，引线长度全看运气。
没文档。
没人记得。
很多团队上来就想先把文档补全，对着100多万行的代码逐行捋，捋了三个月，最后还是漏了十几个藏在边角的特殊逻辑，上线测试的第一天就炸了两个模块。说白了，你永远没法100%搞懂一个跑了十几年的系统到底在做什么——它甚至自己都不知道，自己在某次版本迭代里，被加了多少没有记录的临时补丁。
别上来就喊”全量重构”
我见过太多团队，一接触老系统就皱眉头，觉得代码写的烂，没有分层，没有设计模式，拍板就要全量重构，上微服务，上云原生，一步到位。听着爽对吧？但代价呢？全量重构的成本，从来不是开发团队敲多少行新代码的钱，是你要承担的业务停摆风险。
之前接触过一个做区域零售的团队，当年拍板全量重构会员系统，前后折腾了14个月，上线第一天，会员积分计算错了，当天接到3000多客诉，最后赔了几十万的优惠券才把事压下去。
遗留系统改造最划算的路径，从来不是一步到位换全新系统，是像给飞行中的飞机换引擎——拆一块，换一块，飞着换。
很多团队不愿意这么干，为什么？因为渐进式改造没有爽点。全量重构上线那天，大家可以剪彩，可以发通稿，可以拿项目奖金。但渐进式改造是啥？是每周抽两个小时，把老系统里的一个模块拆出来，和新系统做接口对接，跑一周验证，没问题再拆第二个。没有掌声，没有表彰，甚至业务部门还会觉得你天天在瞎折腾，耽误他们干活。
我见过最实在的一个技术负责人，改他们家的ERP系统，花了三年，每次只改一个部门的模块，改完就让对应的部门用，出问题立刻切回老系统，三年下来，老系统的代码量从120万行降到了不到10万行，整个过程没有一次超过4小时的业务中断。没人给他发奖，但是业务部门再也没骂过系统卡。
别把老系统当垃圾
很多人提到遗留系统，第一反应就是落后，就是要尽快换掉的包袱。但你真的蹲在机房待过就知道，这些跑了十几年的系统，踩过的坑，是多少新系统换上来要重新踩一遍的。
就拿财务系统举例子，里面的那些特殊逻辑，什么跨年度的账怎么调，什么不同地区的税务申报特殊要求，这些东西，新开发的团队根本不可能在三个月的需求调研里摸透。你把老系统扔了，等于把这十几年里所有业务踩过的坑、攒的经验全扔了，新系统要重新花好几年的时间，把这些坑再踩一遍。
真正值钱的从来不是代码本身，是代码里藏着的、没写在文档里的业务规则。
之前和一个做了20年企业软件的老架构师聊天，他说现在很多年轻工程师，看老系统的代码就皱眉头，觉得写的烂，没有设计模式，上来就想推翻重写。但他说，你别光看代码写的糙，你想想，这系统跑了十几年，从来没出过影响核心业务的大故障，这本身就是本事。
我之前接触过一家银行的核心系统，跑了22年，代码是COBOL写的，现在全世界能写COBOL的人都快退休了，银行当年算过一笔账，要把所有的业务规则从老代码里扒出来，整理成文档，再重新开发一套新的核心系统，成本是每年掏200万返聘退休的老工程师维护老系统的8倍。你说选哪个？
很现实。
不浪漫。
但这就是真实的改造现场，不是PPT上画的光鲜的数字化转型蓝图。上次和那个在北欧做户外向导的前工程师聊天，他说当年写那段2016年的工单系统代码的时候，根本没想到这个系统能跑这么久，也没想到会给后来的人留这么多麻烦。我说没事，大家都这么过来的。你留的那些”别改这里”的注释，已经帮后来的人省了至少一半的坑。
他笑。