完美不是过度设计，而是需求偏差
Perfection Is Not Over-Engineering
我常听到团队说'我们不追求完美'，仿佛完美是个贬义词。其实，过度设计的真凶从来不是'做得太好'，而是'解决了错误的问题'。当你把系统当作产品，真正厘清用户需求和约束条件时，你会发现：在特定约束下，往往只有一个解是完美的。比如选Python还是其他语言，用Django还是Flask，答案取决于你的具体场景。过度设计常源于模糊的需求，导致团队用微服务解决本不需要的问题，牺牲数据一致性换取虚幻的独立部署。记住，完美不是敌人，模糊的要求才是。
"过度设计是解决错误的问题，而不是做得太多或太好。"
HN 评论区
- 有评论者反驳原文定义，指出过度工程并非解决错误问题，而是投入了远超必要的时间与资源去解决正确的问题。
- 一位资深从业者强调，最佳工程实践是接受不完美，优先以最小复杂度获取 80% 的核心价值，而非追求难以定义且不断变化的完美约束。
- 亲历者分享了一次因团队缺乏 C 语言人才而强行重写为 Go 的失败案例，证明技术选型往往受限于人员约束而非纯粹的技术优劣。
- 有观点认为，在安全关键领域必须追求 Correctness 和完美，因为微小的差距可能导致严重漏洞，这与'足够好'的通用原则形成张力。
- 评论者指出，'Worse is better'理念之所以能胜出（如 Linux），是因为其注重速度和动量，往往能击败理论上更完美但迭代缓慢的方案。