如果一段代码活了三十年，原作者已经离世，最终却被一个完全陌生的开发者修好，你会怎么想？这不是文学化的设问。上周，类似的事情发生在 Roedy Green 的代码上。
Roedy Green 因“如何编写不可维护代码”而广为人知。他在 2023 年去世，但他留下的软件并没有因此停止运行。事情的起点，是开发者 lexvalo 试图把自己制作的 AI 应用 RiverScript 提交到一些老牌桌面软件目录站，随后发现这些站点依赖的一段老代码仍然存在问题。
这类故事真正值得关注的地方，不只是“老程序竟然还能运行”，而是陌生开发者接手遗留系统时，如何在缺少原作者、文档和上下文的情况下，判断问题、控制风险，并完成一个足够小但确实有效的修复。
遗留代码最难的不是改，而是理解
维护三十年前的程序，通常会同时面对几种不确定性：
- 代码为什么这样写，已经没有人能解释。
- 原来的运行环境可能已经消失，现代工具链也未必兼容。
- 某些看似奇怪的行为，可能已经被其他程序当成稳定接口。
- 修复一个边界问题，可能会改变目录站、脚本或用户的既有工作流。
因此，遗留代码维护的第一原则不是重构，而是建立行为基线。先确认程序现在做什么，再讨论它应该做什么。
可以把维护任务拆成三个问题：
- 输入是什么，输出是什么？
- 哪些行为是明确的缺陷，哪些只是陌生的设计选择？
- 修改后，如何证明没有破坏原有调用者？
这也是为什么一个陌生人有时反而能修好老代码：他没有原作者的惯性假设，会更专注于可观察的输入、输出和失败案例。
“不可维护”不等于“没有价值”
“如何编写不可维护代码”这个标题本身带有讽刺意味，里面列举的很多做法，例如晦涩命名、隐含状态、缺乏解释的技巧性代码，在今天仍然是工程团队反复遇到的问题。
但不可维护的代码并不等于没有价值。只要它仍然被使用，就会不断积累一种特殊资产：稳定的外部行为。维护者往往不能直接推倒重写，因为真正依赖它的对象可能并不在代码仓库里，而是在外部目录、自动化脚本、历史数据和用户习惯中。
这带来一个现实判断：遗留系统的“正确性”不只来自代码结构，也来自它与外部世界已经形成的约定。修复者需要尊重这些约定，同时把明确的缺陷隔离出来。
一个可复制的遗留代码接手流程
下面是一套可以用于类似任务的最小流程。示例假设项目是一个命令行工具，入口文件为 legacy_tool.py，运行环境是 Python 3。实际项目可能使用其他语言，但思路相同。
先建立一个干净的工作副本，并记录当前行为：
git clone https://example.com/legacy-tool.git
cd legacy-tool
python3 --version
python3 legacy_tool.py --help
python3 legacy_tool.py sample-input.txt > before-output.txt
sha256sum before-output.txt
上面的仓库地址只是示例，实际使用时替换为项目的真实地址。before-output.txt 是修改前的行为记录，不能把它当作绝对正确的答案，但它能帮助维护者识别无意中的变化。
接着，为已知问题增加一个最小回归测试。假设问题是输入文件为空时程序崩溃，可以这样组织测试：
# tests/test_empty_input.py
import subprocess
import sys
from pathlib import Path
ROOT = Path(__file__).resolve().parents[1]
ENTRYPOINT = ROOT / "legacy_tool.py"
def test_empty_input_exits_cleanly(tmp_path):
empty_file = tmp_path / "empty.txt"
empty_file.write_text("", encoding="utf-8")
result = subprocess.run(
[sys.executable, str(ENTRYPOINT), str(empty_file)],
capture_output=True,
text=True,
)
assert result.returncode == 0
assert result.stderr == ""
这个测试并没有假设内部实现，也没有要求一次性重写整个程序。它只固定了一个外部承诺：空输入应该能被干净处理。若真实需求是返回特定错误码或输出特定文本，就应把断言改成项目实际约定。
修改前后，可以用相同输入做差异检查：
python3 legacy_tool.py sample-input.txt > after-output.txt
diff -u before-output.txt after-output.txt || true
python3 -m pytest -q
diff 出现变化并不自动意味着修复失败。关键是逐项判断：变化是否由目标缺陷引起，是否影响已有调用者，是否需要补充测试说明。对老系统来说，能够解释每一处变化，比单纯追求测试全绿更重要。
陌生维护者应该留下什么
一次成功的遗留代码修复，交付物不应只有一个补丁。至少应该留下三类信息：
- 问题描述：什么输入会触发问题，实际影响是什么。
- 行为边界：哪些旧行为被保留，哪些行为被有意改变。
- 验证方法：别人如何在当前环境中重现问题并运行测试。
这些信息比“大规模重构”的承诺更有用。因为下一位维护者可能同样不了解项目历史，真正能帮助他的是可重复的命令、明确的样例和简短的决策记录。
还需要警惕一个常见误区：看到老代码难读，就立刻把它改造成现代风格。重构当然可能是长期方案，但在没有测试覆盖、没有完整调用方清单的情况下，重构会把一个可定位的问题扩散成大量难以解释的行为变化。
三十年代码给现代团队的提醒
Roedy Green 的故事提醒我们，软件寿命往往比作者预期得更长。代码可能离开原团队，却继续服务于某个目录站、脚本、格式转换流程或用户习惯。
接手遗留代码时，可以用下面的清单作为最低要求：
- 先运行现有程序，记录真实行为。
- 先修复一个可复现的问题，不要顺手重写全部模块。
- 给目标缺陷补一个回归测试。
- 使用相同输入比较修改前后的输出。
- 明确记录兼容性边界和未解决的问题。
- 把运行命令、环境要求和样例输入写下来。
好的维护并不一定意味着把旧代码变得漂亮。很多时候，它只是让下一位陌生开发者能够看懂一次失败、验证一次修复，并在几年后继续接着工作。能做到这一点，三十年前的代码就还没有真正失去生命力。