完美不是过度设计 — var0.xyz

“我们不想做得完美。” “我们不想构建完美的解决方案。”我已经数不清听过这句话的版本了，就好像“完美”是一个肮脏的词一样。我理解这种谨慎——过度设计会烧伤团队，人们已经学会将任何看似完美的事物视为同样的风险。

事实并非如此。业界已悄然将两者混为一谈。

过度设计正在解决错误的问题。这就是整个定义。不是“过度关心”。不是“做得太好了”。解决错误的问题。通常是出于良好的意图，但几乎总是伴随着越来越多的附带复杂性。

有一个完美的解决方案

我相信存在一个完美的解决方案。有一个重要的警告：您需要一组非常明确的要求。表上的每个约束。把这些拧得足够紧，一些有趣的事情就会发生，你最终只会得到一种可能的解决方案。有点讽刺的是，这个解决方案是完美的。它是完美的，因为它是唯一适合的。

开始一个新项目。每种语言、每种工具、每种可用的托管模型。你选择无服务器。 Python 是一个强有力的选择：无需编译步骤，将文件上传到 Lambda，然后发布。对于其他人来说，这是错误的选择，他们不了解 Python，或者他们需要针对不同的要求（例如性能）进行优化。不同的约束，不同的答案。相同的问题空间，不同的“完美”。

或者您选择了 Python 并且正在构建一个 Web 应用程序。 Django 还是 Flask？两者都可以达到类似的结果。它们仍然是具有完全不同理念的不同工具。哪一个获胜？这取决于。设定更明确的要求，设定更严格的约束，解决方案随之而来。对于这种情况，该解决方案是最适合您的解决方案。

系统即产品

当系统过度设计时，原因几乎总是需求。我指的是产品意义上的要求，而不仅仅是技术方面的要求。

一个库、一个 API、一个内部工具……我们喜欢假装这些是“纯粹的技术”，它们在某种程度上不属于产品的概念。他们不这样做。你有用户。这些用户有需求。您需要充分了解这些需求才能正确满足它们。

也许他们需要的是服务。或者也许由库提供比 HTTP 调用更好的服务。也许你不是给他们一个 API，而是给他们一个包。只有当您将系统视为产品并诚实地定义需求时，解决方案的形状才会变得明显。那么解决方案如下。

你怎么知道

最清楚地表明某些东西是过度设计的：你开始问为什么东西是这样建造的？答案并不成立。

经典例子。一个三人团队维护五个微服务。这些服务相互共享数据。是否过度设计？找出他们试图解决哪个问题。您很可能会得出结论，他们正在解决错误的问题（或同时解决其中的几个问题）。

看看分割的实际成本是多少。曾经是数据库中的硬引用，引擎为您强制执行的外键，现在是字段中的松散字符串 ID。数据完整性消失了。一个服务可以删除一条记录，而另一个服务却不知道；它只是保留一个悬空的引用，并在以后发现，这是一个艰难的方法。当服务都是同一域的一部分时，为什么要在服务之间进行所有这些仪式呢？为什么要放弃这些完整性检查？

交换中你得到了什么？通常：没有你失去的那么多。当然是独立部署，但这真的是您遇到的问题吗？三人一域。你解决了一个没有摆在桌面上的扩展和所有权问题，并为此付出了分布式不一致、运营开销和一个只能部分解决多个问题（但没有完全解决）的系统的代价，同时引入了一堆你本来不会遇到的问题。

这就是签名。不是优雅。不彻底。并不是说这些解决方案不好，它们通常是所提出问题的正确答案。问题是这些是你从未遇到过的问题。

收集正确的要求

所以诊断很简单，即使工作并不简单。过度设计是需求收集的失败。如果你愿意的话，可以将其称为产品工程。这是收集错误需求，然后针对这些需求进行努力设计的结果。

完美从来都不是敌人。要求不明确。把这些做好，把所有的限制都摆在桌面上，完美的解决方案就不再是幻想。它成为唯一留下来的东西。

我制作了这个论点的视频版本，如果你愿意观看的话：完美并不是过度设计。

感谢您的阅读。