是否有其他人认为简单项目的解决方案经常过度设计？

Question

不知何故，我感觉很多项目都变得过度设计，因此每个可能的变更请求都可以解决，因为发生的变更请求很难实现。

不知怎的，我几乎在我正在进行的每个项目中都有这种感觉。就像每个人都在考虑“我们可以添加哪个很酷的api，框架等来解决这个问题和那个方面”而不评估它是否实用或需要。

有没有其他人在这里感受到相同或社区的意见？

Answer 1

是

- MarkusQ

Answer 2

我发现，虽然一些拥有“高级”高级管理人员的老公司往往对其业务代码的创建方式非常严格，但新公司完全缺乏他们用来完成工作的软件的支柱。

您描述的问题听起来像是人们在过高的水平上查看问题，并希望一次性找到解决问题的方法。从长远来看，创建一个工作工具箱（想想标准库）可以帮助他们。

我特别喜欢UNIX的方式：几个小实用程序做一件事并做得很好。

Answer 3

绝对 - 我认为人们过于频繁地混淆“强大而模块化”和“过度工程化”。

Answer 4

我认为Dave Winer captured the cyclical nature of this phenomenon很好：

  

每个周期的诀窍就是战斗   复杂性，所以增长可以保持   去。但是你无法阻止它，   工程师喜欢复杂，而不仅仅是   因为它为他们提供了工作保障，   也因为他们真的很喜欢它。   但是一旦堆栈变得过于神秘，   下一代投掷他们的手   并且说“我们不打算交易   那个烂摊子。“

Answer 5

罪名成立。与简单的流控制分支相比，三个抽象级别和六个配置文件实现起来更有趣。

Answer 6

过度工程是任何项目的危险，无论大小。在编写代码可扩展性时，总是需要在编写足够通用且可扩展的代码以便进行未来开发以及特定的代码来完成手头的任务之间进行权衡。

每个“未来的钩子”都有成本，应根据成本，使用它的概率以及游戏后期的重构成本进行评估。 “更通用”并不总是更好。

至于使用热门的新框架或API，我认为项目经理应该对此采取温和的态度。随着发展成为一个快速发展的领域，实践自我培训是开展业务的一部分（但显然应该保持合理。）

Answer 7

我只遇到过Java用户：“让我们用春天！”并且休眠！我发现了这个很酷的验证包！这个将创建XSLT来创建XML表单来创建javascript！“

当我找到所有的罐子并让它们玩得很好的时候，我必须要熟悉几十个课程。然后他们想抽出所有这些碎片！ “我们可能会将弹簧切换出来。或者不使用休眠，所以我们应该将它们抽象出来”。添加另外十几个hacky包装类。

当它全部完成时，50行假代码变成了数千行使“酷的东西”起作用，并且大约100行业务逻辑被困在其毛茸茸的，黑客的，虫子缠身的地狱中。 / p>

我自己也犯了罪，但那只是因为我很无聊而且有时间杀人。

Answer 8

这里要记住的关键是时间。一个“简单”的项目在第一天被Excel电子表格或网页淘汰，可以迅速扩大其受众和范围，成为一个不可持续的怪物。

工程设计也是一种危险。这个世界充满了“实际”的人，他们会嘲笑任何违背他们观点的努力。没有人记得一年后不同意这个“简单”解决方案无法维持的人。

诀窍是平衡正确的工程程度，并能够在事情发生变化时进行调整。

Answer 9

我被一些快速拼凑在一起的应用程序咬了太多次，这些应用程序随后变成了“关键”应用程序。然后我几乎要重写这个愚蠢的东西。我现在假设它将变得至关重要，所以我第一次“正确地写”。从长远来看，节省了我的时间和精力。奇怪的是，这是关于懒惰的。

Answer 10

今天的xkcd是绝对真理：

我发现过度工程是无聊的副产品。我相信杰夫和乔尔在一个播客中报道了这一点，但想法是那些经常过度工作的程序员可能只是陷入困境并需要改变节奏（杰夫和乔尔建议允许他们做像质量保证这样的不同工作）。 / p>

Answer 11

是。我认为现在人们更多地考虑应该如何做某事，以及“这是正确的方式......”等等，而不仅仅是选择能够完成工作的简单解决方案。如果您没有被要求扩展它，那么不要考虑扩展它。

Answer 12

我认为这是一个问题，但没有看起来那么大，而且有很好的理由。

问题在于，大多数未经设计的项目将会快速死亡，而过度工程的项目可以存活下来。因此，当你看到仍然存在的项目时，存在生存偏见。

而且，即使你是一个很好的建筑师，其目标是“足够好”，如果有疑问，你将使用更灵活，可扩展，......（即过度设计）的解决方案。因为失败模式如果你不满足要求（无论它们是什么）通常比你超过它们时发生的情况要糟糕得多。

Answer 13

我还没有解决任何现实世界的问题，但我已经阅读了足够的人在博客上写这个假设存在问题。

Answer 14

绝对。但它不仅仅是开发人员，也是用户。 “我想要这个，那个和另一个，以改善沟通和提高生产力！”。

我很惊讶我们通过在文件服务器上放置共享文件夹解决了多少这类项目。

Answer 15

正如其他人所说，我已经有太多'小'项目变成了大项目，而且捷径也变成了油漆。

有一个快速和肮脏的解决方案的地方，并试图遵循YAGNI的口头禅，我创建了简单的应用程序，没有工程。

尽管如此，如果没有在小型系统上练习，你将无法跳入百万线系统并开发“精心设计”的系统。

我在所有项目中始终遵循公司的开发架构，因为它帮助我根据我们想要遵循的工程原则制定解决方案。

你练习，表演，所以总是尽力而为。