在写完代码几周后再来审查自己的代码，是一种特别的体验。当时感觉显而易见的决策，现在看来很可疑。"临时"的快捷方式还在那里。而一些你当时确信是对的东西，结果有 bug，你可以直接追溯到某个凌晨两点做出的假设。
我对我最近写的两个项目做了深度审查：Strata——一个对开发环境状态做快照的环境考古工具，以及 branchfs——一个带写时复制语义、为 AI 智能体优化的分支文件系统。两者都是 Python，都不超过 2000 行，都写得很快。以下是我发现的。
几个月前，我开始认真审查 Leverage——一个在生产运行多年的 NestJS Online Judge 平台。零测试。没有 lint 强制执行。没有正式的审查流程。只有在 deadline 压力下一个功能接一个功能长出来的代码。
最终我整理出了 29 个问题。有些是小的风格问题，有六个是那种让你盯着屏幕半天想"这个……一直在跑？"的 bug。
这篇文章讲的是那六个。
在深入具体 bug 之前，先说说我的方法论。审查一个大型的、零测试的代码库，靠随机探索是不行的，你会漏掉东西。我用了三个切入点：
1. 用 commit 历史作为 bug 地图。 名字是 fix/issues、hotfix/ranking 这类的分支是金矿。commit message 告诉你开发者知道什么出了问题。倒着读那些 diff——fix 之前的代码就是你要在代码库其他地方寻找的东西。
