2018年，我接手了一个电商网站的维护工作。核心文件是1.4万行PHP，处理结账流程。原作者两年前离职，变量名混杂匈牙利命名法、缩写和私人恩怨。注释指向早已不存在的Bug，工单系统已经停用。我问团队从哪开始，他们说："别动。"

这个建议当年是对的。现在不是了。

打开网易新闻 查看精彩图片

遗留代码重构曾是资深工程师的噩梦——三个月周期，以迁移失败告终。现在同样的工作缩短到几周，失败率大幅下降。Claude Code改变了游戏规则。不是因为它替你重构，而是因为它承担了曾经让这项工作无法推进的研究负担。

以下是我在 deadline 不可调整、团队无暇支援的情况下，重构陌生代码库的工作流。

为什么重构会失败

遗留项目通常以三种方式崩盘。第一种是范围蔓延：从"清理结账模块"滑向"重写一切"，三个月后零产出，六个月后项目取消，原代码仍在运行。

第二种是回归事故。改动看起来正确，却破坏了承载关键行为的代码。三周后生产环境触发边缘案例，团队回滚，重构信任崩塌，后续项目更难获批。

第三种是烂尾。团队遭遇意外复杂情况，暂停。暂停变成永久。半年后生产环境残留半重构代码，维护难度翻倍——现在它同时存在两种模式。

三种失败模式根源相同：改动前对代码理解不足。遗留代码外表简单，实则不然。每行代码都有存在理由：有些合理，有些过时，有些是为已修复的依赖Bug打的补丁。不仔细阅读无法区分，而没人想仔细读1.4万行遗留PHP。

遗留代码不是烂代码，是幸存代码。生存本身就是信息。大多数重构失败，是因为丢弃了这些信息。

考古学技能

每次重构都从考古开始。这项技能接收文件或模块，输出包含以下章节的Markdown报告：表面摘要——代码表面功能；隐藏行为——命名无法体现的微妙逻辑；依赖关系——它依赖什么，什么依赖它；历史背景。