完美并非过度工程

# 完美并非过度工程 — var0.xyz 来源：https://var0.xyz/posts/perfection-is-not-over-engineering.html 2026-07-19 “我们不想追求完美。” “我们不想构建完美的解决方案。” 这句话的变体我已经听过无数次，仿佛“完美”是个脏话。我理解这种谨慎——过度工程会消耗团队，人们已经习惯把所有带有完美意味的东西视为同样的风险。 事实并非如此。整个行业在不知不觉中将两者混为一谈。 过度工程是*解决错误的问题*。这才是完整的定义。不是“过于上心”，也不是“做得太好”。而是解决错误的问题。通常出发点是好的，但几乎总是伴随着不断堆积的意外复杂性。 ## 存在一个完美的解决方案 我相信完美的解决方案是存在的。但有一个重要前提：你需要一套非常明确的需求。把所有约束都摆在台面上。将这些约束收窄到足够程度，有趣的事情就会发生——你最终只会得到唯一可能的解决方案。而那个方案，有点讽刺地，就是完美的。它之所以完美，*正是因为*它是唯一符合的方案。 开始一个新项目。每种语言、每种工具、每种托管模式都可用。你选择无服务器。Python 是强有力的选择：无需编译步骤，上传文件到 Lambda 即可发布。但对另一个人来说，这可能是错误的选择——他们不懂 Python，或者需要针对性能等不同需求进行优化。不同的约束，不同的答案。相同的问题空间，不同的“完美。” 或者你选择了 Python，正在构建一个 Web 应用。Django 还是 Flask？两者都能达到类似的结果。但它们仍然是具有完全不同理念的工具。哪个胜出？取决于你。设定更清晰的需求、更严格的约束，解决方案自然随之而来。那个方案对你来说，在那个场景下，就是完美的。 ## 系统就是产品 当系统被过度工程时，原因几乎总是需求问题。我指的是产品意义上的需求，而不仅仅是技术层面的。 一个库、一个 API、一个内部工具……我们喜欢假装这些是“纯粹技术性的”，认为它们以某种方式超脱于产品的概念。它们并不。你有用户。那些用户有需求。你需要足够理解这些需求，才能恰当地满足它们。 也许他们需要的是一项服务。或者用库比用 HTTP 调用更好。与其提供 API，不如提供一个包。只有当你把系统当作产品，并诚实地定义需求时，解决方案的形态才会变得清晰。然后解决方案自然就出来了。 ## 如何判断 判断某样东西过度工程的最明显标志是：当你开始问*“为什么这些东西要这样构建？”*，而答案站不住脚时。 经典例子。一个三人团队维护着五个微服务。这些服务之间相互共享数据。这算过度工程吗？弄清楚他们试图解决什么问题。你很可能会得出结论：他们正在解决错误的问题（或者同时解决好几个）。 看看拆分带来的实际成本。原本数据库中一个硬引用——引擎为你强制维护的外键——变成了字段中一个松散的字符串 ID。数据完整性不复存在。一个服务可以删除记录，而另一个服务毫不知情；它只是继续保留一个悬空引用，日后再以艰难的方式发现。既然所有服务都属于同一个领域，为什么要在它们之间添加这么多仪式？为什么要放弃那些完整性检查？ 你得到了什么作为交换？通常：失去的远多于得到的。独立部署，没错，但这真的是你实际遇到的问题吗？三个人，一个领域。你解决了本不在议程上的扩展和所有权问题，却用分布式不一致性、运维开销以及一个部分解决多个问题但一个也没有彻底解决的系统来买单，同时还引入了一堆本不会出现的问题。 这就是迹象。不是优雅，不是周全。而且这些解决方案本身并不糟糕——它们通常是对所提出问题的正确答案。问题在于，那些问题你从未拥有过。 ## 收集正确的需求 所以诊断很简单，尽管实际操作不容易。过度工程是需求收集的失败。如果你愿意，可以称之为产品工程。这是收集了错误需求，然后勤勉地依此进行工程化的后果。 完美从来不是敌人。模糊的需求才是。把需求弄对，把所有约束摆在台面上，完美的解决方案就不再是幻想。它会成为唯一剩下的东西。 --- 我制作了这篇文章的视频版本，如果你想观看的话：完美并非过度工程（https://youtu.be/YDFzvQpn4mo）。 感谢阅读。