问过度工程、欠工程和右倾有什么区别？

EN

当你做太多的设计来解决一个基本的问题时，你就过度工程了。例如，当您使用抽象的工厂模式“以防万一”来创建一个非常简单的对象时，业务逻辑可以很容易地适应四到五个LOC，您就过度考虑了设计(并且违反了KISS和YAGNI)。

请注意，它不一定需要过于复杂。只要正确命名了类，并且团队的其他成员都知道这个模式，抽象工厂模式就没有什么复杂的了。尽管如此，对于一个不需要任何特定模式就可以解决的问题来说，它仍然是太多的类和代码。

当你做得不够的时候，你就没办法了。例如，如果您的Java代码库大部分位于静态类中的静态方法中，而主要部分在实用程序类中，则您对设计的考虑不够。

请注意，过度工程和欠工程通常是由缺乏经验的程序员通过两种不同的模式完成的：

• 最缺乏经验的人对设计模式了解不够，往往不使用它们，也不太重视设计。他们让他们的代码在很少或根本没有设计的情况下成长，发现这样的代码更容易阅读和理解。
• 稍微有经验的人谁开始学习设计模式有一个倾向于应用这些模式在任何地方，以显示他们知道他们。我们应该创建一个对象吗？让我们使用带有抽象构建器和具体构建器的构建器模式。需要在两个对象之间进行通信？让我们使用适配器模式！显然，fluent界面很有趣，因为它让我们编写这样的代码: product = ProductBuilder() .setId(39) .setPrice(new .setId.setTitle(“Product1”)，.setDescription("Description goes“) .getResult()，而不是:价格=新价格(59，Unit.Dollar)；产品产品=新产品(39，价格，”产品1"，“描述在这里”)；

它需要更多的技能和经验，以找到黄金中间，也就是说，使用尽可能多的设计，但绝对不再。这就是正确的工程术语的含义，尽管它在行业中并没有那么多的使用，有一个很好的理由。

过度工程和欠工程是用来批评别人的代码的术语，比如在“伙计，停止过度工程你的代码，我们几乎找不到我们的方式，通过几十个类，你不必要地添加！”另一方面，对于其他开发人员来说，开发人员的正确工程的黄金中间不一定是相同的(而且通常也不一样)。最近的回答展示了如何确定在使用工厂或在构造函数中移动逻辑之间的边界是多么不明显。因此，人们不能断言他的代码是正确的，因为至少他的一些同事会不同意。

“过度工程”是指当改进解决方案的成本高于改进解决方案的效益时，即改进解决方案。“在工程中”意味着不改进一个解决方案，因为改进它的好处将超过成本。猜猜“正确的工程”是什么意思..。

由于提到了“简单”解决方案，并以某种方式将其与缺乏经验的开发人员联系在一起，对不起，但是缺乏经验的开发人员往往找不到简单的解决方案。如果有经验的开发人员确实会找到一个简单的解决方案，而且它通常是“正确的工程”解决方案，因为它需要最少的工作量才能得到一个有效的解决方案，它通常是可读性和可维护性的，因为它很简单，而且通常(并不总是)高效，因为它不会在不必要的复杂性上浪费时间。

增加复杂性也不是过度的工程。根据定义，过度工程实际上改善了产品(只是不足以证明改进的成本是合理的)。给出的例子增加了毫无意义的复杂性，一点好处也没有。

当代码完美无缺的时候，代码就不适合设计了。当它达到改进的成本超过改进的好处时，它是正确的设计。如果我们甚至不能同意一个改变是否是一种改进，那么这种改变是否有好处来证明改变它的工作是非常不可能的。

我把描述的两个极端称为“欠工程”和“过度工程”。

它们似乎是指上述链接中的一句话：

在我的经验中，有两个开发人员性格类型的极端:那些总是寻求和解决最简单的解决方案，和那些寻求完美的解决方案，完美的效率，可读性或代码优雅。

这些似乎不是广泛使用的术语，他用它们来解释其余的文章中的概念。

我可以说：

那些总是用最简单的解决方案寻找和解决问题的人，...总是制造混乱

这显然不是我给“简单解决方案”下的定义。

这些是有趣的读物，谢谢。目前，我正在读乔治·费尔班克斯( George )的一本书，名为“刚刚足够的软件架构”。在这种情况下，我可能会把过度工程(工程师太多)定义为在设计阶段花费太长时间，尽管你也可以在编码的同时进行工程。该书强调了一种风险驱动的方法。识别风险，估计风险，确定任务的优先次序，并相应地进行工程师。你可能也觉得这很有趣。