完美不是过度设计，而是需求偏差
Perfection Is Not Over-Engineering
我常听到团队说'我们不追求完美'，仿佛完美是个贬义词。其实，过度设计的真凶从来不是'做得太好'，而是'解决了错误的问题'。当你把系统当作产品，真正厘清用户需求和约束条件时，你会发现：在特定约束下，往往只有一个解是完美的。比如选Python还是其他语言，用Django还是Flask，答案取决于你的具体场景。过度设计常源于模糊的需求，导致团队用微服务解决本不需要的问题，牺牲数据一致性换取虚幻的独立部署。记住，完美不是敌人，模糊的要求才是。
过度设计是解决错误的问题，而不是做得太多或太好。
HN 评论区
123- __MatrixMan__
我完全支持反对'别让完美成为优秀的敌人'这种说法。我经常听到人们用这句话为那些通常很糟糕、甚至有点邪恶的软件辩护——除了某个可怜虫试图让自己的工作变得值得骄傲之外，根本看不到任何好地方。
不过我不确定我是否同意'系统即产品'这个观点。产品思维是有毒的。这意味着你的目标与用户的目标是独立的（通常是赚钱，有时甚至意味着为了股东利益对用户做点卑鄙的事）。
所有优秀的软件都更偏向'工具'类别，而非'产品'类别。通常它们是由用户自己制作的，只专注于解决他们遇到的问题，没有任何 ulterior motives（不可告人的动机）。
- qsort
我不会说'过度设计意味着解决了错误的问题'。有可能这个想法本身基本正确，但人们把精力花在了优化那些实际上并不存在、或者在有了更清晰的图景后可以处理的约束条件上，无论是那个神话般的 PMF，还是仅仅是'我们现在明白用户想要什么了，那就去造吧'。
我参与过的最混乱的项目是一个 Web 应用，它实际上相当好地解决了一个真实问题，但团队却花时间构建了一个荒谬的鲁布·戈德堡式微服务装置，而整个平台的月活用户数（MAU）还不如我的个人爱好网站。这并非解决了错误的问题，但这绝对是过度设计！
- nickelpro
'我们这里并不是要构建一个完美的解决方案'这句话，并不是用来安抚过度设计或鼓励草率工作的。
它是为了堵住某一类特定工程师的特定抱怨，这些人会反对说，由于没有覆盖某些在生产环境中极少出现的边缘情况，所以提议的解决方案行不通。
'我们这里并不是要构建一个完美的解决方案'的意思是：'我们承认无法面面俱到，我们将需求设定在第 90 百分位的用例上'。
- epolanski
我认为'完美'是个脏词，因为它对人类思维有有害的影响。
追求完美往往会导致过度设计，但我认为更重要的是，它还会导致：由于追求完美而产生过多的修车轱辘（bike shedding），以及当我们没能做出完美之物时背负的大量情绪包袱。
就连作者也承认，他们对完美的定义只有在极其严苛的需求下才会产生。我要更进一步地说，也许它对于那个特定问题、那个特定时间是完美的，但猜猜看，变化无处不在。作为架构师，我们必须像思考当前问题一样思考未来的问题。考虑到这一点，我认为拥有一个在许多场景下都'足够好'的东西，比拥有一个仅在起始场景下'完美'的东西更好。
- MantisShrimp90
这里的保留意见是，正如 TFA 所述，你需要'把所有约束条件都摆上台面'。而这几乎从未发生过。除非你是在一个成熟的领域里创造东西，那里的一切都已被探索过，否则你根本_不知道_约束条件是什么。
你可以花三个月时间在白板会议上规划出完美的解决方案，但一旦开始实施，你的计划就会瞬间崩塌，因为现实世界会强加给你一些实际上无法先验知晓的约束条件。请注意，这并非理论上不可能。如果你足够聪明，并且花足够多的时间去思考，你本可以想到它们。但你不够聪明，而且你没有时间。这些就是宇宙强加给你的其他约束条件。