完美并不是过度工程
软件工程中的“完美”是一个有争议的话题：有人认为在需求清晰时存在一个“完美”解，另一些人则认为现实中的约束、不断变化的目标和人为因素使这种想法不现实，甚至有害。评论者把真正的技术质量与优雅简洁，同过度工程——例如不必要的微服务架构或过度测试——进行对比，并强调不清晰或不断演变的需求是臃肿系统的主要来源。许多人主张务实的中间路线：在重要的地方追求高质量，接受已记录的缺口和边缘情况，并认识到截止日期、预算和未来变化本身也是塑造“够好”应当意味着什么的约束。
“过度工程”是什么意思
- 提供了几种定义：
- 解决了错误的问题，或者针对你实际上并不存在的约束进行优化。
- 与收益相比引入了不必要的复杂性（例如：为很小的用户基数构建大量微服务）。
- 过度建造 vs 过度工程：前者是“太强”，后者是“对于需求来说太复杂”。
- 也有人指出，这个术语常被误用来表示“我不理解这个”，或者用来贬低优雅的抽象。
完美 vs “够好就行”
- 许多人批评“不要让完美成为优秀的敌人”这句话只是陈词滥调，经常被用来为交付低质量、脆弱的系统找借口。
- 另一些人则为它辩护，认为它可以防止人们陷入无休止的打磨，或者在处理极其罕见的边缘情况时陷入僵局。
- 有人认为工程中的“完美”应当意味着“在明确定义的约束下保持正确”，而不是神经质式的完美主义。
- 还有人说真正的完美并不存在；大多数问题都有多个带权衡的解决方案，而不是单一最优解。
需求、约束与不断变化的现实
- 一个强烈的主题是：大多数过度工程都源于糟糕、缺失或不断变化的需求。
- 对文章论点的批评者说：
- 约束是灵活的，会彼此权衡，而且会随着时间变化。
- 你几乎从来不会“把所有约束都摆在桌面上”，因此声称存在唯一“完美”解决方案是不现实的。
- 在存在未知未知的情况下，迭代式方法（构建–观察–改进）被认为更诚实。
架构选择与微服务
- 微服务被反复提及为经典的过度工程：当它们被用于并不存在的规模、HA 或团队独立性时尤其如此。
- 有人认为微服务主要解决的是组织扩展问题（康威定律）；把这套东西复制到小团队里，就像“为一个个人博客建立一个内部经济体系”。
边缘情况、可靠性与值班取舍
- 关于忽略罕见场景的争论：
- 管理者/产品通常推动 90 分位解决方案。
- 负责凌晨 2 点事故的工程师，不愿被告知忽略那些罕见但具有破坏性的故障。
- 建议的折中方案是：明确记录不支持的情况，记录日志，并避免阻碍未来演进。
测试、质量与成本收益
- 过度工程也可能表现为过多的单元测试覆盖率，或沉重的 QA 流程，它们拖慢功能开发，却未必提升真实世界的可靠性。
- 强调成本收益/FMEA 思维：在严重性和发生概率足以证明投入合理的地方重金投入，在其他地方接受缺口。
实践中的完美主义
- 有人认为长期不发布的副项目和无休止的重写，是广泛存在的完美主义表现。
- 另一些人则说，在职业环境中，真正的问题是欠工程化、意大利面条式系统，而不是传说中的完美主义者。