我想知道应用于软件开发的术语“过度工程”的良好定义是什么。在软件设计讨论中,该表达似乎经常与“过分的面向未来”结合使用,并且最好确定一个更精确的定义。
19 回答
与大多数答案相反,我不认为“目前不需要的功能”是过度设计的。或者它是问题最少的形式。
就像你说的那样,最糟糕的过度工程通常是以面向未来和可扩展性的名义进行的 - 并达到完全相反的效果:
- 空的抽象层充其量是不必要的,最坏的情况是限制您对底层 API 的狭隘、低效使用。
- 代码中充斥着指定的“扩展点”,例如通过抽象工厂获取的受保护方法或组件——当您必须扩展功能时,这些都不是您真正需要的。
- 使一切都可配置以“避免硬编码”,其效果是配置文件中的应用程序逻辑比源代码中的更多(复杂、容易出错)。
- 过度通用化:开发人员没有实现(技术上无趣的)功能规范,而是构建了一个(技术上有趣的)“业务规则引擎”,它自己“执行”业务用户提供的规范。最终结果是一种专有(脚本或特定领域)语言的解释器,这种语言通常设计得很糟糕,没有工具支持,而且很难使用,以至于没有业务用户可以使用它。
事实是,最容易适应新的和不断变化的需求的设计(因此是最具前瞻性和可扩展性的)是尽可能简单的设计。
在我们考虑过度设计的情况下,它总是在描述被设计为非常通用的软件,以至于它忽略了最初设计执行的主要任务,因此不仅变得难以使用,但从根本上说是不聪明的。
对我来说,过度设计包括任何你不需要并且你不知道你会需要的东西。如果你发现自己说如果需求以某种方式发生变化,一个特性可能会很好,那么你可能是过度设计了。基本上,过度工程违反了YAGNI。
这个问题的敏捷答案是:每段代码都对请求的功能没有贡献。
如果你花太多时间思考一个问题的可能后果,以至于最终干扰了问题本身的解决,那么你可能会过度设计。
“最佳工程实践”和“现实世界的适用性”之间有一个很好的平衡。在某些时候,您必须决定,即使从工程的角度来看,某个特定的解决方案可能不像它可能的那样“纯粹”,但它会完成这项工作。
例如:
如果您正在设计一个在高中同学聚会中一次性使用的用户管理系统,您可能不需要添加对超长名称或时髦字符集的支持。设置一个合理的最大长度并进行一些基本的清理就足够了。另一方面,如果您正在创建一个将部署用于数百个类似事件的系统,您可能希望在该问题上花费更多时间。
这一切都与手头任务的适当努力水平有关。
这与我有争议的“最简单的方法永远是最好的方法”的编程观点有关。
恐怕不可能有一个精确的定义,因为它高度依赖于上下文。例如,过度设计一个显示闪闪发光的小马的网站比设计一个核电站控制系统要容易得多。冗余、过多的错误检查、高度仪表化的日志设施对于闪闪发光的小马应用程序来说都是过度设计的,但对于核电站控制系统来说却不是。我认为你能做的最好的事情就是感觉到你何时为了应用程序的目的而对你的功能应用了太多的开销。
请注意,我会区分镀金和过度工程。在我看来,镀金正在创造一些没有被要求也永远不会被使用的功能。过度工程更多地是关于通过围绕代码进行编码检查或对简单任务使用过度设计来为应用程序构建多少“安全性”。
从这里引用:“......当你真正需要它们时实施它们,而不是在你预见到你需要它们时。”
对我来说,任何东西都会给代码增加更多的脂肪。Meat 可以是任何可以根据规范完成工作的代码,而 fat 可以是任何会使代码膨胀而只会增加复杂性的代码。程序员可能一直期待功能的未来扩展;但是还是很胖!
当您的设计实际上使事情变得更复杂而不是简化事情时,您就是在过度设计。
更多信息请访问:
我的粗略定义是“提供不需要满足需求规范的功能”
过度工程化意味着根据需求列表使用比实际应有的组件更多的组件来架构和设计应用程序。
过度工程和创建可扩展的应用程序之间有很大的区别,可以随着需求的变化而升级。如果我能想到一个例子,我会编辑帖子。
过度工程只是简单地创建一个产品,其功能、质量、通用性、可扩展性、文档或任何其他方面都超出了要求。
当然,您可能有特定项目之外的需求——例如,如果您预计将来会做类似的应用程序,那么您可能有额外的可扩展性需求,取决于成本,您添加到项目特定需求中。
免责声明#1:我是一个大局的BA。我不知道代码。我一直在阅读这个网站。这是我的第一篇文章。
有趣的是,我的老板刚刚告诉我,我过度设计了一个我们计划指导的新软件产品(目标市场人力资源人员)。所以我来这里查一下这个词。
他们希望现在就出售一些东西,重新利用现有工具。我不禁坐下来思考,更少的注册,更低的保留,如果它不允许我们谈到的一些灵活性。主要是有一个猴子可以使用的高度可视化的 UI。
他说我们可以计划未来的阶段来改进产品,尤其是 UI。我们目前的客户正在等待我们仍然没有做的“未来改进”。他们需要它,真的需要它。
我正在辞职,所以我没有退缩。
但我的定义是......确保它只做尽可能少的事情,尽可能便宜,并且对于你所说的事情仍然可以接受。除此之外就是过度工程。
免责声明 #2:这个网站帮助我找到了下一份工作,实施了一个更可配置的软件。
我认为您的问题的最佳答案可以在其他问题中找到
敏捷编程的美妙之处在于,如果你做得对,就很难过度设计。