程序员该不该重复造轮子？Quinn 这段脚注说得更准

Andrew Quinn 写了一篇关于用 10MB FST（finite state transducer，有限状态转换器）二进制文件替代 3GB SQLite 数据库的文章。Simon Willison 摘出来的重点，却不是这次替换本身，而是 Quinn 放在脚注里的一段职业忠告。

这段话戳中的是程序员很熟的一种焦虑：我正在写的东西，会不会 30 年前就有人写过更好的？Quinn 举的例子很小：你想写一个懂 TSV 的搜索替换工具，后来发现 awk 早就能解决一整类问题。

他的判断也很短：这种负罪感是陷阱。不是成熟工具没价值，而是害怕重复发明，常常会把人困在被动学习里。资料越查越多，手越不敢伸出去。

Quinn 反对的是工具焦虑，不是成熟工具

Quinn 的意思不能读偏。

他没有说 awk 过时，也没有说 SQLite 不好。恰恰相反，他用 awk 这个例子承认：很多问题早有漂亮解法，前人确实把路铺过一遍。

但他反对把这件事变成心理刹车。因为“别人可能已经做得更好”，所以自己永远停在阅读、收藏、比较、犹豫里。这不是谦虚，是被工具史吓住了。

这里的关键词不是“轮子”，是“边界”。

只会调用现成库，能交付很多东西。但你可能不知道库为什么这么设计，慢在哪里，错在哪里，哪些边界条件被藏起来了。

反过来，什么都自己写，也不是高级。那很容易把工程做成手工艺展。漂亮，但没人敢接。

真正该分清：训练判断，还是制造负债

我更在意这段话对两类人有用。

一类是有工具焦虑的程序员。看到一个问题，第一反应是搜框架、搜包、搜最佳实践。搜不到，就怀疑自己问错了问题。

这类人该做的，不是拒绝工具，而是给自己留一小块练手区。写一个小搜索器，理解索引；写一个简陋解析器，理解语法和错误恢复；写一个玩具数据库，理解事务、存储和查询计划为什么麻烦。

另一类是正在从教程学习转向独立工程判断的开发者。你不再只需要“怎么用”，你需要知道“为什么这样用”。这一步靠刷教程很难过去，必须亲手撞几次墙。

“纸上得来终觉浅”放在编程里一点不虚。很多知识不是看懂的，是被 bug、性能瓶颈、边界条件逼出来的。

但限制也要说清楚。

学习里的重造，是低成本试错。目标是增长判断。

生产里的重造，是长期承诺。目标是稳定交付。

把学习逻辑搬到线上系统里，常常会留下维护债；把生产逻辑套到学习阶段，又会培养出只会拼装、不会判断的人。

接下来最该观察的变量也很具体：你能不能说清自己为什么重写。

如果答案是“为了理解一个概念、验证一个边界、拆开一个抽象”，可以做，小做，做完复盘。如果答案是“我觉得现成方案不够酷”，最好停手。团队项目里还要再加三问：谁维护、谁排障、谁为线上事故负责。

软件业爱现成答案，但工程判断来自拆过几只轮子

软件行业有一种很现代的便利：工具链越成熟，人越容易把理解外包出去。

短期看，这能提高效率。框架、云服务、托管数据库、现成 SDK，确实让很多项目跑得更快。团队交付不是修行，能复用就该复用。

问题是，工程判断不是乘客能力。系统正常时，你可以相信抽象；系统坏掉时，你得知道抽象下面是什么。

铁路时代不需要每个乘客懂蒸汽机，但司机和修理工不能只会买票。软件开发者如果太早把自己放进“只会使用”的位置，职业上限会来得很快。

Quinn 这段脚注好就好在没有浪漫化“造轮子”。他说的不是一千个，也不是零个。多数领域四五个，严密领域二三十个。这个数字不是公式，但态度很准：实践要够多，多到长出直觉；也要够克制，别把时间烧成手工癖。

所以，这件事不是“拒绝工具”。

更好的读法是：成熟工具当然要用，但别急着把全部好奇心交出去。你至少要亲手拆过几只轮子，才配说自己是在复用，而不是在依赖。

开头那个问题也就有了答案：程序员该不该重复造轮子？该，但只在学习和校准判断时该。到了生产环境，轮子不是作品，是责任。