每个Java开发者都可能遇到这样的场景：接手一个运行了八年以上的遗留系统，没有文档、没有测试、作者已经离职、依赖的框架早已停止维护。代码中充斥着复制粘贴、注释掉的代码块、意义不明的变量名。任何一个微小的修改，都可能触发未知的连锁反应。
参考：https://xrzqr.cn/category/disaster-warning.html
面对这样的系统，“重写”是最本能的冲动。但现实往往是：业务部门不会给你半年的时间从头重写；重写的风险可能比维护遗留系统更高；业务逻辑的复杂性远超你的想象，重写可能遗漏重要的边缘情况。
在这样的约束下，如何在不重构（或有限重构）的前提下，安全地维护和演进遗留系统？这是一门关于“风险控制”的工程艺术。
第一条生存法则是：不要触碰你不理解的东西。在遗留系统中，有些代码看起来“多余”或“奇怪”，但它的存在可能有着历史原因——修复了某个特定环境下才出现的Bug，处理了某个特殊客户的数据格式。盲目删除或修改这些代码，可能会在数月后触发一个难以排查的生产问题。当你必须修改一段不理解的代码时，先做“防护性修改”——只增加代码，不删除代码；只添加新的分支逻辑，不修改原有的控制流；在修改的代码块周围添加充分的日志输出，以便在出问题时能够快速定位。
第二条生存法则是：用测试建立安全网。在修改遗留代码之前，先为要修改的部分编写“特征测试”——通过大量输入输出观察当前代码的实际行为，将这些行为固化到测试用例中。特征测试不关心代码“应该”做什么，只记录代码“实际”做什么。有了特征测试的保护，你可以确信修改不会改变原有的行为（无论这个行为是否正确）。为遗留代码编写测试非常困难，因为这些代码通常没有设计为可测试的。静态方法、单例模式、硬编码的依赖——这些都是测试的障碍。PowerMock、Mockito等工具可以在一定程度上突破这些障碍，但更好的策略是“接缝”技术——在修改代码时，先引入一个小的“接缝”（如提取一个protected方法、添加一个构造函数参数），让代码变得可测试，然后编写测试，最后进行实质性的修改。
第三条生存法则是：依赖升级要谨慎。遗留系统通常依赖大量旧版本的框架和库——Spring 3.x、Hibernate 2.x、Struts 1.x。直接升级到最新版本几乎不可能，因为API的变化会引发大规模的编译错误。正确的做法是“分步迁移”。首先，确保当前版本的所有功能都有充分的测试覆盖；然后，升级到一个中间版本（如从Spring 3升级到Spring 4），修复由此引起的编译错误和运行时问题；在确认系统稳定后，再升级到下一个中间版本。这个过程可能需要多个迭代周期，但每一步的风险都是可控的。对于无法升级的依赖，可以采取“隔离”策略——将使用旧版本库的代码封装在独立的模块中，其他模块通过明确定义的接口访问。当最终需要替换该库时，只需要重写这个隔离模块，而不影响系统的其他部分。
第四条生存法则是：使用静态分析工具理解系统。SonarQube、SpotBugs、Checkstyle等静态分析工具，可以对遗留代码进行“体检”——识别出重复代码、过长方法、过高圈复杂度等问题区域。这些问题区域通常是最需要修改、也是最容易出Bug的地方。架构分析工具（如JDepend、ArchUnit）可以帮助你理解模块之间的依赖关系。在遗留系统中，模块边界常常已经崩溃——一个包中的类可能直接访问另一个包中的内部实现。通过分析依赖关系，你可以识别出最混乱的区域，在进行大范围修改前优先处理这些区域。
第五条生存法则是：在安全的前提下进行增量重构。完全不重构是不可能的——每次修改代码，都需要理解现有代码；每次理解现有代码，都会发现可以改进的地方。但重构不能在真空中进行，它需要测试的保护和业务价值的驱动。一个实用的策略是：每次修改某个模块时，让该模块比之前“稍微好一点”。重命名一个意义不明的变量、拆分一个过长的方法、删除一段注释掉的代码——这些小改进累积起来，能够逐渐改善系统的可维护性。这就是“童子军规则”——每次离开营地时，让它比你发现时更干净。
第六条生存法则是：建立“知识库”而非“文档”。传统的“设计文档”在遗留系统中几乎总是过时的。取而代之的是“常见问题排查指南”——当生产环境出现问题时，如何快速定位和修复？这类“情景式”的知识，对于维护遗留系统更有价值。团队Wiki中的“已知问题”列表、“修改历史”记录、“诡异行为”说明，都是宝贵的知识资产。当新成员加入时，这些资料能够帮助他们更快地理解系统的“潜规则”。
第七条生存法则是：接受不完美。遗留系统能够运行至今，说明它在某些方面是“足够好”的。不是所有的不规范都需要纠正，不是所有的技术债务都需要偿还。评估每个问题的“风险/收益”比，只处理那些真正影响开发效率和系统稳定性的问题。有时，最好的修改就是不修改。如果一个模块稳定运行了五年，没有出现过Bug，即使它的代码写得很丑，也不要碰它。价值在于系统的行为，而不是代码的美观。
参考：https://xrzqr.cn/category/weather-science.html
遗留系统的维护是一门平衡的艺术。你需要在业务需求和代码质量之间平衡，在短期进度和长期可维护性之间平衡，在理想愿景和现实约束之间平衡。一个成功的遗留系统维护者，不是那个把代码写得最漂亮的人，而是那个让系统持续稳定运行、让业务需求持续被满足的人。
在Java生态中，有些遗留系统已经运行了十五年以上。它们承载着核心业务逻辑，每天处理着海量交易。这些系统是公司的核心资产，也是开发者职业生涯中最具挑战性的战场。掌握遗留系统的生存技能，是每个资深Java开发者必备的能力。
参考：https://xrzqr.cn
