是否有OOP过度复杂化的术语？

一两年前，我看到了一篇有关OOP（Java）的出色文章，其中展示了一个简单的两行或三行代码的具体记录器的发展，以及经验不足的开发人员在理论上的过度思考过程，基本上说，哦，我应该添加此以防万一我们想要的！ 到本文结尾时，这个简单的记录器是一堆乱七八糟的垃圾，原始开发人员几乎无法理解自己。

这种过度并发症是否有一个通用术语？那篇文章（我非常希望我能再次找到它）很好地展示了一个孤立案例的概念，但是我遇到了整个项目，在这些项目中，开发人员实际上是由于过度使用模式，框架，库和程序而陷入困境。其他问题。用它自己的方式，这比我们继承来替换的旧版VB6意大利面条应用程序糟糕（甚至更糟）。

我真正想要的是在面试时提出这个问题。我想知道是否有人意识到并意识到缺乏架构/预先规划就容易陷入这种困境（并且因为他们似乎没有适当的平衡而陷入困境），但这并不是真的我可以找到很多信息。

我听到的描述此类设计的最常用术语是过度工程。但是，该词的原始含义与软件开发无关，在软件开发之外，它可能没有那么糟糕的基调。

在更一般的层面上，乔尔·斯波斯基（Joel Spolsky）为过度复杂的建筑设计的设计师提供了“ 建筑宇航员 ” 的名称。

但是，特别是对于采访而言，我认为了解相反的含义更重要，只将实际需要的东西放到设计中，而忽略不健康的“以防万一”方法-这就是所谓的YAGNI原则。

是的，过度工程是描述这一点的最简单术语。多年来，我看到过度设计，不必要复杂的设计的次数比我所记得的要多。许多年前，当参加Microsoft GWBasic课程时，讲师反复敲击KISS方法（保持简单愚蠢）。今天和今天一样。

因此，我始终记得KISS，并始终牢记SOLID原则进行设计。但话虽如此，仍然有可能在充分考虑SOLID原则的情况下对设计进行过度设计。您必须在常识，务实的方法与纯正的愿望之间保持平衡，并遵守普遍接受的OOP准则。如果有足够的时间，并且喜欢创建复杂的解决方案，那么您最终可能会为滑板设计引擎，因为您认为它最终会变成汽车。幸运的是，多年来，我已经受到足够的训练，没有这样做，但是我已经看过很多次了。

综上所述，为防止代码过于复杂：

1）吻（保持简单愚蠢）

2）牢记实用性，遵循SOLID原则。

3）不要试图为所有可能的情况进行设计。有时，小的泄漏性抽象不是可怕的事情，如果它们是孤立的，有意的，并且防止它们的努力远远超过保持它们的效果。

4）在设计解决方案时考虑解决方案的实施。您不能只说“哦，这是实现细节”，并假设您的设计是可行的。我曾经和一位经常这样做的建筑师一起工作，可惜他的设计从未奏效，结果，我不再在那里工作。

5）编写代码，就像您将要维护它一样。

因此，您将进行这次面试，并打算诱使应聘者展示他对软件工程的了解，然后您会说：“不，您可能想将您所知道的全部应用到您的第一份工作中，现在就继续前进。 ，您就是镀金的过度设计的非商业价值创造者！Shoo！”

我认为提供一个具体的示例并讨论应用某些模式的利弊会比较安全。比您要征求诸如“这取决于您，您是否想要它快吗？这就是全部吗？问题有多复杂？已经建立了哪些模式？”之类的响应。您可能会自己学到一些东西。这也将使候选人证明自己的背景意识，而这将是一个更为开放的问题。等待并想要一个特定的答案最多可以使您得到与您同样最大的担忧。如果您没有得到答案，那么候选人可能会认为这很容易。