设计模式是否不受欢迎？

Question

我和我们的一位资深开发人员进行了一次讨论，他已经在这个行业工作了20年。他写了一篇博客，在安大略省很出名。

奇怪的是，他告诉我:他说有一段代码是一场噩梦，因为它是从教科书上写来的，不考虑现实世界。向UI/数据库/数据层添加一个新字段需要2-3个小时，而在他的代码中则需要30分钟。

另一件事是，他避免了设计模式，因为大多数程序员都不理解它们，而且从维护的角度来看，它们也不是很好。

还有一种想法是，加拿大的大多数web开发人员更愿意让他们的数据模型继承数据层类，而不是保持数据层类的隔离。我问他：“将模型与数据层分离不是行业标准吗？”他有时说，但这里的大多数人不喜欢那样做，因为这是太多的工作。

听起来，他之所以不使用最佳实践进行编码，是因为这是一场维护噩梦，我们的员工很少了解这一点(除了我自己)，而且如果你需要在几天内推出新特性或字段，那么使用起来会很慢。

听到这样的观点太奇怪了，因为Stack溢出主要鼓励人们遵守行业标准。问题是，我们总是被迫在几天内生成新的字段和特性，而不可能推断出足够灵活的坚实模式吗？这似乎是我从中了解的要点。

你对这些陈述有什么看法？

Answer 1

这是一些人的话，他们发现了成功，却忽视了那些试图用他不懂的模式行话来告诉他该怎么做的人。

设计模式和最佳实践不是一回事。有些人认为自己是疯子，并驱使那些知道自己在做什么的人。即使他们不知道他们所做的事情的正确名称。

设计模式在有名字之前就已经存在了。我们给他们起了名字让他们更容易谈论。一个有名字的模式并不能使它成为一件好事。它使它成为一种可识别的东西。

这家伙很可能在使用你们都没听说过的模式。好吧，除非你需要和他谈谈事情是怎么做的。他要么要学怎么跟你说话要么你得学会怎么跟他说话。与谁是“对的”无关。

Answer 2

许多设计模式，就像您和您的朋友所描述的那样，实际上只是解决编程语言中的缺陷的方法。使用一种更有表现力的编程语言，对这些设计模式的大部分需求就消失了。

由于需要良好的设计模式来满足许多可能的使用场景，它们往往是过度设计的。过度设计的代码是有代价的:你必须阅读它，理解它所做的，以及理解它在整个软件系统中是如何工作的。因此，与任何其他软件开发技术一样，您必须根据使用该技术的成本来评估该技术，并决定其收益是否超过成本。

在所有其他条件相同的情况下，更少的代码总是更好。我已经经历过分层架构，您实际上需要在多个项目中进行三到六个跳，才能找到任何有趣的代码，也就是说，代码实际上可以完成其他任务，而不是增加开销。

众所周知的软件模式应该为您提供一个通用的词汇，您可以通过它来交流设计策略。不幸的是，许多软件开发人员没有很好地理解软件模式词汇表，无法正确地将其应用于他们的编程问题。缺乏经验的开发人员认为这些模式属于专家的范围；他们希望被看作是专家，因此他们试图过早地学习和应用这些模式，然后才做好准备。他们真正应该做的是先学习编程的基本原理，然后尝试解决每种模式自己解决的问题。如果他们这样做，他们将处于一个更好的位置，以正确地理解和应用模式。

Answer 3

Stackoverflow.SE和Programmers.SE主要鼓励人们遵循可靠的最佳实践，而不是行业标准。信不信由你，事实上的行业标准通常是“大泥球”体系结构--认真地说。

但要直接回答您的问题:设计模式的问题与继承问题相似--许多平庸的开发人员过度使用它们，这有一定的风险造成过度设计，难以维护代码。但答案肯定不是完全避免或禁止使用设计模式(或继承)，答案是学习在有意义的情况下使用这些工具，而且只有在这种情况下才有意义。这是完全独立于工作的“敏捷”或不。