什么是应用于软件的“过度工程”？ [关闭]答案

【问题标题】：What is "over-engineering" as applied to software? [closed]什么是应用于软件的“过度工程”？ [关闭]
【发布时间】：2010-11-03 07:42:00
【问题描述】：

我想知道应用于软件开发的“过度工程”一词的良好定义是什么。在软件设计讨论中，该表达似乎经常与“过分的面向未来”结合使用，最好确定一个更精确的定义。

【问题讨论】：

您可能应该为此应用“主观”标签。
@abmv 我完全不同意。关于软件开发过程的问题是完全合法的。
看到这个问题stackoverflow.com/questions/750112/…
“与编程无关”？ Erm、软件设计、反模式和开发方法不是“与编程有关”？
所以，请容忍这样一个与软件开发相关的好问题，尽管它不是一个特定的编程问题！

标签： terminology definition

【解决方案1】：

与大多数答案相反，我不认为“目前不需要的功能”是过度设计的；或者它是问题最少的形式。

正如您所说，最糟糕的过度工程通常是以面向未来和可扩展性的名义进行的 - 并达到完全相反的效果：

空的抽象层充其量是不必要的，最坏的情况是限制您对底层 API 的狭隘、低效使用。
代码中充斥着指定的“扩展点”，例如通过抽象工厂获取的受保护方法或组件 - 当您必须扩展功能时，所有这些都不是您真正需要的。
使所有内容都可配置以“避免硬编码”，结果是配置文件中的应用程序逻辑比源代码中的更多（复杂、容易出错）。
过度通用化：开发人员没有实现（技术上无趣的）功能规范，而是构建了一个（技术上有趣的）“业务规则引擎”，它自己“执行”业务用户提供的规范。最终结果是一种专有（脚本或特定领域）语言的解释器，这种语言通常设计得很糟糕，没有工具支持，而且很难使用，以至于任何业务用户都无法使用它。

事实是，最容易适应新的和不断变化的需求（因此是最具前瞻性和可扩展性）的设计是尽可能简单的设计。

【讨论】：

有趣的想法是，当一个人试图找到一个技术上有趣的问题而不是仅仅实现一些无聊的东西时，就会发生过度设计。我猜有些事情要小心。
我喜欢最后一段！
有很多构建规则引擎的好方法。在我的上一份工作中，我用一个更好的引擎替换了一个坏引擎。但你是对的；你所描述的正是第一个引擎发生的情况。

【解决方案2】：

与流行的看法相反，过度设计确实是一种现象，当工程师变得“自大”并认为他们了解用户时就会出现这种现象。

我做了一个简单的图表来说明这一点：

【讨论】：

看起来像癌症。
很好的插图。如果我可以问的话，你是用什么把这些放在一起的？
图像模糊并被 photobucket 徽标覆盖

【解决方案3】：

在我们考虑过度设计的情况下，它总是在描述被设计为非常通用的软件，以至于它忽略了最初设计要执行的主要任务，因此不仅难以使用，但根本不智能。

【讨论】：

【解决方案4】：

对我来说，过度设计包括你不需要的任何东西，而且你知道你会需要。如果你发现自己说如果需求以某种方式发生变化，一个特性可能会很好，那么你可能是过度设计了。基本上，过度工程违反YAGNI。

【讨论】：

【解决方案5】：

这个问题的敏捷答案是：每段代码都对请求的功能没有贡献。

【讨论】：

【解决方案6】：

Joel on Software 有这样的讨论，开头是，

为尚不存在的想象中的未来问题创建广泛的类层次结构是一种过度设计，因此是不好的。

然后，通过示例进行讨论。

【讨论】：

这是另一个关于框架过度工程的文章：discuss.joelonsoftware.com/default.asp?joel.3.219431.12
软件链接上的 Joel 似乎已损坏。

【解决方案7】：

如果您花太多时间思考问题的可能后果，以至于最终干扰了问题本身的解决，那么您可能会过度设计。

“最佳工程实践”和“现实世界的适用性”之间有一个很好的平衡。在某些时候，您必须决定，即使从工程的角度来看，一个特定的解决方案可能不像它可能的那样“纯粹”，但它可以完成这项工作。

例如：

如果您正在设计一个在高中同学聚会时一次性使用的用户管理系统，您可能不需要添加对超长名称或时髦字符集的支持。设置一个合理的最大长度并进行一些基本的清理就足够了。另一方面，如果您正在创建一个将部署用于数百个类似事件的系统，您可能希望在这个问题上花费更多时间。

这完全取决于手头任务的适当努力水平。

【讨论】：

【解决方案8】：

恐怕不可能有一个精确的定义，因为它高度依赖于上下文。例如，过度设计一个显示闪闪发光的小马的网站比设计一个核电站控制系统要容易得多。冗余、过多的错误检查、高度仪表化的日志设施对于闪闪发光的小马应用程序来说都是过度设计的，但对于核电站控制系统来说却不是。我认为您能做的最好的事情就是了解何时为了应用程序的目的而对您的功能应用了过多的开销。

请注意，我会区分镀金和过度工程。在我看来，镀金正在创造一些没有被要求也永远不会被使用的功能。过度工程更多的是关于通过围绕代码进行编码检查或对简单任务使用过度设计来为应用程序构建多少“安全性”。

【讨论】：

【解决方案9】：

这与我对"The simplest approach is always the best approach" 的有争议的编程观点有关。

【讨论】：

【解决方案10】：

Quoting from here: "...在你实际需要时实施，绝不是在你预见需要时实施。"

【讨论】：

请不要以这种理念为核反应堆开发软件；）
点对了，但我会在这里争论语义，并说当涉及可能影响安全或健康的软件时，您实际上需要几乎所有可能的保护措施。

【解决方案11】：

对我来说，任何东西都会给代码增加更多的脂肪。 Meat 可以是任何可以根据规范完成工作的代码，而 fat 可以是任何会使代码膨胀而只会增加复杂性的代码。程序员可能一直期待功能的未来扩展；但是还是很胖！

【讨论】：

【解决方案12】：

我的粗略定义是“提供不需要满足需求规范的功能”

【讨论】：

什么是潜规则？它们通常不在规范中，但需要满足才能提供强大的解决方案。
如果他们没有说出来，你怎么知道你什么时候让他们满意？
过度工程通常从需求阶段开始。我记得一个 SSADM 项目在编写一行代码之前就生成了大约 5000 页的需求文档。
@Visage，这是一个很好的问题。通常通过用户验收测试，尽管为时已晚。敏捷建议以短迭代和大量用户参与的方式解决方案。
但是用户验收测试人员如何知道通过测试的标准是什么？敏捷不能替代需求。

【解决方案13】：

我认为它们与Gold plating 相同并被Golden hammer 击中:)

基本上，您可以坐下来花太多时间尝试做出完美的设计，而无需编写代码来检查它是如何工作的。任何敏捷方法都会告诉您不要预先完成所有设计，而只是创建设计块、实施它、重复它、重新设计、重新设计，等等......

【讨论】：

【解决方案14】：

过度工程化意味着根据需求列表构建和设计应用程序时使用的组件数量超出实际应有的数量。

过度工程和创建可扩展的应用程序之间存在很大差异，可以随着需求的变化而升级。如果我能想到一个例子，我会编辑这篇文章。

【讨论】：

【解决方案15】：

过度工程只是创建一个产品，其功能、质量、通用性、可扩展性、文档或任何其他方面都超出了要求。

当然，您可能有特定项目之外的要求——例如，如果您预计将来会做类似的应用程序，那么您可能会根据成本对可扩展性有额外的要求，并将其添加到项目的特定要求中。

【讨论】：

【解决方案16】：

当您的设计实际上使事情变得更复杂而不是简化事情时，您就是在过度设计。

【讨论】：

【解决方案17】：

免责声明 #1：我是一个大范围的 BA。我不知道代码。我一直在阅读这个网站。这是我的第一篇文章。

有趣的是，我的老板刚刚告诉我，我过度设计了一个我们计划指导的新软件产品（目标市场人力资源人员）。所以我来这里查一下这个词。

他们希望现在就出售一些东西，重新利用现有工具。我不禁坐下来想一想，如果它不允许我们谈到的一些灵活性，那么更少的注册，更低的保留率。主要是要有一个猴子可以使用的高度可视化的 UI。

他说我们可以计划未来的阶段来改进产品，尤其是 UI。我们目前的客户正在等待我们仍然没有做的“未来改进”。但他们需要它，真的需要它。

我正在辞职，所以我没有退缩。

但我的定义是......确保它只做尽可能少的事情，尽可能便宜，并且仍然可以接受你所说的事情。除此之外就是过度工程。

免责声明 #2：这个网站帮助我找到了下一份工作，实施一个更可配置的软件。

【讨论】：

【解决方案18】：

我认为您的问题的最佳答案可以在this other qestion中找到

【讨论】：

这应该是注释号吗？

【解决方案19】：

敏捷编程的美妙之处在于，如果你做得对，就很难过度设计。

【讨论】：

但是你最终可能会得到一个大规模过度设计的测试套件:)（掩护鸭子）
如果你写了一份宣言，定义什么是“正确的”和什么是“错误的”，然后遵循它，那么是的，做一些“错误”的事情可能非常困难。
@0scar：这就是敏捷的重点：你定义什么是正确的。 :)