卡夫卡《在法的门前》：每个程序员都经历过的等待

一扇永远开着的门

卡夫卡写过一个极短的寓言：一个乡下人来到法的门前，请求进入。守门人说，现在不能让你进去。乡下人问，那以后可以吗？守门人说，有可能，但现在不行。

于是乡下人等了一辈子。他变老了，快死了，用最后的力气问守门人：为什么这么多年来没有别人来这扇门？守门人回答：这扇门是专门为你开的，现在我要去关上它了。

故事就这么结束了。没有解释，没有寓意提示，没有大团圆。

程序员的"法的门前"

每个写过代码的人，或多或少都经历过类似的场景——

你想给一个开源项目提 PR。你仔细阅读了 Contributing Guide，写了代码，跑了测试，认真写了 commit message。然后你等着。一周、两周、一个月。Maintainer 说"看起来不错，但需要一些改动"。你改了。又等了两周。又要改。半年后这个 PR 被标记为 stale 然后自动关闭。

你想学一门新技术。你找到了官方文档，但文档的入口指向"Getting Started"，Getting Started 要求你先装一堆依赖，每个依赖又有自己的 Getting Started。你花了三天配环境，还没写一行业务代码。门一直开着，但你似乎永远站在门外。

你想在公司推动一个技术改进。你写了方案、做了 benchmark、准备了 slides。但先要过技术评审，然后要排期，然后要和另一个团队协调接口，然后季度 OKR 变了，你的方案被"暂时搁置"。半年后你发现别的公司已经上线了同样的东西。

等待的本质

卡夫卡的天才之处在于，他没有告诉你乡下人应该怎么做。不等？闯进去？贿赂守门人？这些选项都不存在于文本中。他只是精确地描绘了等待本身——那种"门明明开着，但你就是进不去"的荒诞感。

这种荒诞感之所以在一百年后依然有效，是因为它触及了一个更深的问题：我们有多少次把"条件还不成熟"当作不行动的理由？

"等我学完 X 再开始做项目"——然后你永远在学。 "等这个工具稳定了再用"——然后你永远在等。 "等我准备好了再发布"——然后你永远在准备。

门是为你开的

寓言最刺痛人的一句是最后那句：这扇门是专门为你开的。

这意味着没有人在排队。没有竞争者。没有比你更有资格的人。唯一阻止你进入的，是你对"守门人"的服从——而守门人从来没说过"你不能进去"，他只是说"现在不行"。

在编程的世界里，那些最后真正做成事的人，往往不是等到万事俱备才开始的人，而是在条件还不完美的时候就推门而入的人。代码有 bug？先发了再修。文档不完善？边用边写。技术选型可能错？迭代比选择更重要。

但也别太鸡汤

话说回来，卡夫卡毕竟不是励志作家。他没有给出"正确答案"。也许乡下人闯进去会发现里面还有无穷无尽的守门人。也许真正的问题不是"该不该进去"，而是"为什么我们会相信有一扇门在等着我们"。

不过对程序员来说，有一点倒是确定的：while (waiting) { } 是一个死循环。至少得在里面加个 break 条件。