重构与再工程：老系统的生死劫

2015年，某银行想升级自己的核心系统。那套COBOL写的，跑在 mainframe 上的，代码超过 150 万行。

当时的 CTO 提了两个方案：

方案一：推倒重来。 用微服务架构全新开发，预计 18 个月。结果：上线后 Bug 不断，一年半后回滚。

方案二：再工程。 逆向工程 → 新需求考虑 → 正向工程，用两年时间慢慢迁移。结果：平稳过渡，零故障。

这个故事告诉我们：老系统不是用来重写的，是用来再工程的。

重构？大多数人在"埋雷"

"这段代码太乱了，我们重构一下。"

听到这句话，我一般会问：你说的重构，是哪种？

真正的重构，是在同一抽象级别上转换系统描述形式，不改变系统功能。 说人话：代码变好看了，但做的事一模一样。

举个例：五层嵌套的 if-else，无人敢动的全局变量，按照重构原则，应该优化到"清晰可读"的程度——但功能不能改。这才是重构。

但现实里发生了什么？改着改着，"顺手"加了个新功能；测着测着，发现老逻辑被改坏了；上线后，原来的客户投诉说"以前能用的功能怎么没了"。

这不是重构，这是制造技术债。

逆向工程：从代码逆推设计

逆向工程是另一层意思：从程序中抽象出设计信息，从低抽象往高抽象走。

说白了，就是从代码倒推回设计文档。你以为的"理解系统"，在这个词面前才算真正开始。

很多遗留系统为什么没法改？不是代码乱，是没人知道这段代码在干什么——写代码的人离职了，文档早就丢了，只有代码还在生产环境跑着，跑得胆战心惊。

逆向工程要回答的问题是：这段代码在设计层面是怎么想的？

再工程：不是重写，是换心脏

很多人把再工程等同于重写。错。

再工程 = 逆向工程 + 新需求考虑 + 正向工程，三个步骤形成循环。

它不是一上来就推翻重来，而是先通过逆向工程理解现有系统，加上对新需求的判断，再用正向工程的方式重建。

区别在哪？

方法	抽象层次	特点
重构	同级转换	不改变功能，只改变形式
逆向工程	低→高	从代码恢复设计
正向工程	高→低	传统开发流程
再工程	循环	理解 + 判断 + 重建

什么场景用什么方法

代码可读性差，业务稳定 → 重构。 优化结构，但不改变功能。核心是"不动手术，只整容"。

遗留系统无文档 → 逆向工程。 先用工具把设计信息恢复出来，理解系统，再谈改动。核心是"先读懂，再动手"。

系统需要升级 → 再工程。 在保留原有功能的基础上，全面重新开发。核心是"换心脏，而不是拆房子"。