2026-07-19 "我们不想做完美。" "我们不想构建完美的解决方案。" 我听过无数次类似的话，这些话似乎把“完美”当作了脏话。我理解这种谨慎——过度工程会伤害团队，人们已经学会把任何闻起来像完美的东西视为同样的风险。但它并不是。行业悄悄地将它们混为一谈。过度工程是解决错误的问题。这就是整个定义。不是“过于关心”。不是“做得太好”。是解决错误的问题。通常是出于好意，几乎总是伴随着日益增长的偶然复杂性。我相信存在一个完美的解决方案。前提是：你需要一组非常明确的需求。所有的约束都要在桌面上。把这些约束收紧一些，会发生有趣的事情，你最终会只有一个可能的解决方案。而这个解决方案，稍显讽刺的是，就是完美的。它是完美的，因为它是唯一适合的。开始一个新项目。每种语言，每种工具，每种可用的托管模型。你选择无服务器架构。Python是个强有力的选择：没有编译步骤，上传你的文件到Lambda，工具就交付了。对某个人来说，这是错误的选择，他们不知道Python，或者需要优化不同的需求，比如性能。不同的约束，得到不同的答案。同样的问题空间，不同的“完美”。或者你选择Python并正在构建一个网络应用。使用Django还是Flask？你可以用两者取得类似的结果。它们仍然是完全不同哲学的工具。哪一个胜出？这要看情况。设定更清晰的需求，设定更严格的约束，然后解决方案就随之而来。那个解决方案是你和那个案例的完美之选。系统就是产品 当一个系统过度工程时，其原因几乎总是需求。我所说的需求是产品意义上的需求，而不仅仅是技术上的需求。一个库，一个API，一个内部工具……我们喜欢假装这些是“纯技术”的，仿佛它们在产品的概念之外。其实不是。你有用户。这些用户有需求。你需要足够了解这些需求，以便妥善处理它们。也许他们需要的是一个服务。或者，一个库可能比HTTP调用更适合满足他们的需求。与其给他们一个API，不如给他们一个包。只有在你将系统视为产品并诚实地定义需求时，解决方案的轮廓才会变得明显。然后，解决方案就来了。 你如何识别过度工程 最明显的标志是：你开始问为什么事情是以这种方式构建的？而答案不成立。经典例子：一个三人的团队维护五个微服务。这些服务之间共享数据。它是过度工程吗？找出他们试图解决哪个问题。大多数情况下，你会得出结论，他们是在解决错误的问题（或者同时解决几个问题）。看看拆分实际的成本。曾经数据库中的硬引用、引擎为你强制的外键，现在只是一个在字段中松散的字符串ID。数据完整性消失了。一个服务可以删除一个记录，而另一个服务对此毫不知情；它只会保持一个悬空的引用，后来才发现，后果很严重。为什么在服务之间做这么多手续，当它们都是同一领域的一部分时？为什么放弃那些完整性检查？你获得了什么作为交换？通常：得到的没有失去的多。独立部署，当然，但那是你实际存在的问题吗？三个人，一个领域。你解决了一个并不存在的扩展和所有权问题，却为此付出了分布式不一致性、操作开销，以及一个部分解决多个问题的系统，而这些问题中的任何一个都没有完全解决，同时引入了一堆你本来不会遇到的问题。这就是标志。不是优雅。不是全面。而且这些解决方案通常并不是坏的，通常它们是针对所提问题的正确答案。问题在于，那些是你从未遇到过的问题。 收集正确的需求 因此，诊断很简单，即使工作并不简单。过度工程是需求收集的失败。你想的话，可以称之为产品工程。这是收集错误需求的后果，然后勤奋地针对这些需求进行工程。完美从来不是敌人。模糊的需求才是。搞清楚这些，把每个约束都列在桌面上，完美的解决方案不再是幻想。它成为唯一留下的东西。我做了一个这个论点的视频版本，如果你更愿意观看：完美不是过度工程。谢谢阅读。