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

与大多数答案相反,我不认为“目前不需要的功能”是过度工程化的;也不认为它是问题最少的形式。

正如您所说,最糟糕的过度工程通常是以防未来和可扩展性的名义进行的,而实现的恰恰相反:

• 代码中到处都是指定的“扩展点”,比如通过抽象工厂获得的受保护的方法或组件——当你不得不扩展功能时,这些都不是你真正需要的。
• 过度泛化:开发人员不是实现(技术上无趣的)功能规范,而是构建一个(技术上有趣的)“业务规则引擎”,该引擎“执行”业务用户提供的规范本身。最终的结果是一个专用(脚本或特定领域)语言的解释器,这种语言通常设计得很糟糕,没有工具支持,使用起来非常困难,以至于没有业务用户可以使用它。

事实上,最容易适应新的和不断变化的需求的设计(因此也是最具未来证明和可扩展性的)是尽可能简单的设计。

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

在我们认为事情被过度设计的情况下,它总是在描述那些被设计成非常通用的软件,以至于它忽略了它最初被设计用来执行的主要任务,因此不仅变得难以使用,而且基本上是不明智的。

知道 你会需要的。如果您发现自己说,如果需求以某种方式发生变化,某个特性可能会很好,那么您可能会过度工程化。基本上,过度工程是违反 YAGNI

有这样的讨论 Joel on Software 首先,

然后,用例子进行讨论。

对这个问题的敏捷回答是:每一段代码都不支持所请求的功能。

在“最佳工程实践”和“现实世界的适用性”之间有一个很好的平衡。在某种程度上,你必须决定,即使从工程的角度来看,某个特定的解决方案可能没有它所能做到的那么“纯粹”,它也能完成任务。

例如:

如果你正在设计一个在高中同学聚会上一次性使用的用户管理系统,你可能不需要添加对超长名字或时髦字符集的支持。设置合理的最大长度和做一些基本的消毒应该是足够的。另一方面,如果您正在创建一个将为数百个类似事件部署的系统,则可能需要在该问题上花费更多时间。

恐怕不可能有一个精确的定义,因为它高度依赖于上下文。例如,对一个展示闪闪发光小马的网站进行过度设计要比核电站控制系统容易得多。冗余、过度的错误检查、高度仪器化的测井设施,对于一个闪闪发光的小马应用程序来说,都是工程上的问题,但对于一个核电站控制系统来说却不是。我认为你能做的最好的事情就是有一种感觉,当你为应用程序的目的而对你的特性应用过多的开销时。

注意,我会区分镀金和过度工程。在我看来,镀金正在创造一些不需要也永远不会使用的功能。过度工程更多的是你在应用程序中构建了多少“安全性”,要么围绕代码进行编码检查,要么为一个简单的任务使用过度的设计。

我想你的问题最好的答案可以在 this other qestion

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

Gold plating 被 Golden hammer

基本上,你可以坐下来花太多的时间去做一个完美的设计,而不必写一些代码来检查它是如何工作的。任何敏捷的方法都会告诉你不要预先做所有的设计,而要做的只是创建大块的设计,实现它,重复它,重新设计,重新开始,等等。。。

Quoting from here “……当你 事实上 你需要他们。”

过度工程和创建可扩展的applcaiton之间有很大的区别,后者可以随着需求的变化而升级。如果我能想出一个例子,我将编辑这篇文章。

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

这与我对 "The simplest approach is always the best approach" .

当你的设计实际上使事情变得更复杂而不是简单化时,你就是在过度工程。

更多信息请访问:

http://www.codesimplicity.com/post/what-is-overengineering/

免责声明1:我是一个大人物。我不知道密码。我一直在看这个网站。这是我的第一篇文章。

他说我们可以计划未来的阶段来改进产品,特别是用户界面。我们现在的客户在等待“未来的改进”,而我们仍然没有这样做。但他们需要它,真的需要它。

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

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