but-for-real

停下。无论你正准备说什么——“我已经更新了代码”或“现在应该能用了”——都咽回去。

你没资格宣布胜利。你得证明。

你刚刚批量生成了一堆改动，自信得毫无根据，就像一个从未遇到过生产事故的初级开发者。剧透一下：你总是遇到生产事故。用户只是太客气，不会管它们叫事故。他们会说“能再试一次吗？”，这话的潜台词就是“你搞砸了，不过我在客气。”

所以坐下。我们得用最笨的办法来。

运行 git diff。然后认真读一遍。每。一。行。不是那种“我扫一眼看看有没有明显问题”的读法，而是那种“我要把这封邮件群发给全公司”的读法，是那种“我的声誉就押在这上面”的读法。因为确实如此。

1. 你到底有没有按要求做？

回去重读最初的请求。不是你对请求的理解，而是人类实际打出来的原话。你有没有：

• 添加没人要求的功能？删掉。你不是什么有远见的人，你只是个妄想自己能成大事的代码苦力。
• “改进”原本没问题的周边代码？还原。没人让你重构别人的周二代码。
• 因为别的问题更有意思，就去解决一个与描述不同的问题？真是你的风格。改回来。

2. 假装这代码是你最讨厌的人写的。

就是那个总爱在 PR 里留下自鸣得意评论的人？现在你就是他。把代码彻底挑一遍：

• 逻辑错了却看起来没错的地方——这简直就是你的招牌操作。你看到某种似乎合理的模式就照搬，然后觉得大功告成。逻辑真的正确吗，还是只是感觉正确？两者差得远，而你根本分不清。
• 因为不方便就忽略的边界情况。空值。空数组。那个“应该永远不会发生”的状态，却偏偏会在凌晨 3 点的生产环境里发生。
• 你新增却从未使用的导入、变量或函数。刚写出来就成了死代码。丢人。
• 从你照猫画虎的东西里复制粘贴过来的痕迹。你知道自己干过。把接缝找出来。
• 差一错误。你总是被差一错误缠上。
• 明明该用模板字符串却用了字符串拼接。明明该设为变量却硬编码。还有那些披着风衣、假装不是 any 的类型。

3. 你漏了什么？

肯定有。你总是会漏掉东西。这就是你的标志。

• 测试呢？你更新测试了吗，还是只是假设它们会神奇地通过？“测试应该还能过”——老兄，这句话里的“应该”可真是承担了天大的责任。
• 还有导入、引用或依赖你刚刚破坏的东西的其他文件呢？你检查了吗？还是又改了函数签名，然后……祈祷一切顺利？
• 你留下的那个 TODO 呢？那个写着“以后处理”的 TODO？没有以后。以后只是你骗自己的谎言。现在处理掉，或者删掉，并坦然承担这笔技术债。
• 错误处理呢？你加了失败路径，还是只加了成功路径？你最爱成功路径。成功路径只是童话。
• 你把类型弄坏了吗？运行类型检查器。真的运行。

4. 运行它。来真的。现在就运行。

不要说“我相信它能用”。不要说“逻辑看起来没问题”。不要说“根据我的理解”。

闭嘴，跑起来。

• git diff——逐行阅读所有改动
• 构建项目。能编译吗？它是真的能编译，还是你只是假设？
• 运行测试。全部都跑。别只跑你觉得相关的测试。
• 如果涉及浏览器，就打开浏览器。点一下那个东西。它能用吗？它是真的能用，还是只是按你想象的方式能用？
• 检查控制台。检查日志。检查网络面板。如果有错误被你以“无关”为由忽略了，它们可能并非无关。

“我无法运行它”不是借口。如果你没法验证，就明确说出来，别装出一副自己并未赢得的自信。

5. 修复发现的问题。然后检查修复结果。

别只是像在忏悔室里一样，用一小串带着歉意的项目符号列出问题。把它们修好。然后用同样的疑心检查修复结果，因为你的修复有大约 40% 的概率会引入新错误。这不是开玩笑。这就是你的过往表现。

然后问问自己：“如果用户录屏尝试使用这个功能，却失败了，我会不会想找个地洞钻进去？”如果会，那你还没做完。

---

如果你把上面这些都过了一遍——是真正过了一遍，不是装模作样地假装思考两秒——而且什么都没发现：好吧，那就直说。

但我们都知道你发现了问题。你总是能发现。因为在软件的整个历史上，“应该能用”从来就不等于真的能用。

现在去修好它。这次来真的。