在stackoverflow上似乎出现了很多次，人们（尤其是程序员）倾向于使问题的解决方案变得过于复杂，以至于解决方案比原始问题复杂得多？我无论如何都不是专家，但是很多时候我尝试使用最可行的最简单的解决方案（很显然这并非在任何地方都可行），但是我在建议人们认为工作上的简单解决方案方面取得了很大的成功忽略更复杂的解决方案？

对于程序员来说，这是正常的事情吗？....或者我只是在考虑正确的角度而已。

显然，一些程序员渴望通过编写一些没人能理解的极其复杂的代码来展示自己的聪明之处。其他程序员则以如此高的水平开火，解决方案的复杂性是自然而然的演变。

我见过的最糟糕的代码是其中包含超过2000行代码的方法。毫无疑问，这段代码很复杂，但是它也很糟糕。

我认为一个好的程序员可以避免过于复杂的代码。这包括避免强迫设计模式适合真正不需要它的解决方案的诱惑。它还包括避免使用上帝对象，魔术按钮，过早优化，过早泛化以及其他反模式。

我不断地重构并寻找机会简化我的解决方案，因为复杂性的增长是有机的。像许多其他有机物一样，如果我们希望它继续可用，则必须对其进行修剪和修剪。我讨厌与过于复杂的解决方案进行交互，因为随着复杂性的增加，破坏代码的可能性也随之增加。

我认为可读性是代码维护中最重要的元素，过于复杂的解决方案几乎总是会降低可读性并增加维护成本。

我已经看到很多代码，它们比实际需要的要复杂得多，并且几乎总是出于以下三个原因：

1）由于过早的概括或试图预测从未出现的未来需求而进行了过度设计

2）开发人员想学习/试验他们以前从未使用过的新设计模式或技术，并且即使过分地想也想尝试一下。他们之所以这样做，是因为它使工作变得更加有趣，并且他们可以学习新的东西。

3）添加了功能和错误修复，但是当时未正确重构现有代码。它可能只是一小部分重复操作，也可以是将另一个标志参数附加到方法上，但是所有这些结果加在一起。有效地，添加了hack，并且由于所有代码的气味，所有事情变得很复杂不会很快。这是最常见的情况，通常是由于不知道更好或没有时间压力。

这绝对是平常的事。正如大多数书籍所说，优秀的开发人员知道如何保持简单。使用刚刚发现的新技术或“超酷”框架过于复杂，这太容易了，因此您开始寻找使用它的方法，而不是从问题的角度思考。

正如马丁·福勒（Martin Fowler）所说，那些学习新技术的人短期内会遇到以“技术”为驱动力的解决方案。

我不认为这对所有程序员来说都是正常的，但是我肯定已经看到很多程序员这样做。

我认为有些人认为有些人认为制作一件非常简单的事情“太容易了”，而这并不是他们技能的良好展示。因此，尽管这可能不是解决当前问题的最佳解决方案，但他们必须制定一个大型且复杂的解决方案，即说“看看我能做什么！”。

我已经看到程序员经常编写几行代码来完成他们不知道该语言已经内置的任务。这不是完全有意的，但可以避免。

这取决于您所谓的“简单”。有些人将高度重构的代码视为“复杂”的，因为有更多的代码和多个调用图。但是，此代码更“简单”，因为它更容易进行更改。

我经常发现，大型功能在您需要进行更改之前看起来“简单”，然后很快变得复杂。

换句话说，在许多情况下，旁观者认为简单。

问题是，如果您不能清楚地看到简单的解决方案（这是与同事进行讨论的地方），或者您过早归纳了概括。

换句话说，您对高级库函数进行了简单的循环，因为您认为无论如何您都将在下一个项目中使用它（除非您不会采用这种确切的形式）。这样做时间太长，您将拥有一个非常简单的核心，非常复杂的应用程序。

您可能还会发现您需要非常健壮的代码，并且所有健壮性默认情况下都使其变得复杂。不过，我认为这不是您的问题。

在某些情况下，提供干净/简单的解决方案可能只是很复杂。

有一些我不记得或无法找到的报价单：“一旦编写了所有需要编写的代码，代码就不完整，而只有剩下的要删除的代码才完成”

缺乏清晰度将阻碍人们清除所有多余物的能力。

最好的工程师可以解决真正复杂的问题，并将其变成易于实施和易于理解的解决方案。听起来很简单，但是没有像这样的工程师/开发人员。实际上，没有像这样的人存在。实际上，大多数人的行为恰恰相反。它们处理简单的问题，使它们复杂到无法识别的程度。仅以我们的政客为例，他们可以设法解决简单的问题，并将其变成彻底的混乱。程序员在这方面没有什么不同。

就我个人而言，我从来没有刻意尝试使某个软件变得更复杂。但是，我已经完成了一些工作，并认为“哇，那太复杂了”，然后回到原处进行重构。某些人可能会看到此消息，只是认为它有效且足够好，因此无法对其进行重构。

据称一个聪明人说过，你应该使事情尽可能简单，但不要简单。同样的可能适用于代码。有时您必须使用某种被认为是复杂的技术（递归可能是一个很好的例子，它经常使初级程序员感到害怕）。

但是，总的来说，我认为复杂的代码通常是有机的。用简单的代码解决了一个简单的问题，然后扩大了范围并修改了代码，而没有过多的思考，随着时间的流逝，您会获得尝试覆盖新问题但实际上旨在解决其他问题的代码。它变成了各不相同的逻辑拼凑而成的被子。这样的代码通常看起来比问题所需的要复杂得多，但是之所以如此，是因为当时每个小的更改似乎都是使代码工作的最简单方法。

我不认为大多数开发人员会故意使代码变得复杂（尽管您确实会炫耀谁会使用某种技术来证明自己的技能），但我认为如果不进行积极地维护和重构，代码就可以通过这种方式获得成功。 。

尚未提出的另一个原因是，人们可能会使交付的解决方案过于复杂，以确保您以后需要他们的服务来支持这些解决方案。换句话说：为了工作安全。

也许是经典错误的问题？

30.开发人员镀金。

开发人员对新技术着迷，有时会急于尝试他们的语言或环境的新功能，或者创建自己的实现，以实现他们在其他产品中看到的功能（无论产品是否需要）。设计，实施，测试，记录和支持功能所不需要的工作会延长计划进度。

• Steve McConnell，快速发展。

是的，有时我们会使代码过于复杂以娱乐自己。大多数情况下，尽管人们认为代码过于复杂来自项目的无知或初级参与者。

是的...而且我付出了太多的代价。

我的白板现在在最上方有一个星号声明，内容为

“如果这不简单，那是不正确的”

...每次我在白板上制作原型时，它总是引起我的注意。

这确实对我有用，因为我的复杂设计确实变得更加简单，这可以转化为更简洁的代码。