欣赏优秀设计的价值

Question

最近，我和一群人(来自两家不同的公司)一起工作，刚毕业或者有1-2年的工作经验，他们对各种行业术语和设计模式等的知识印象深刻。此外，他们每个人都对OO设计原则和界面的使用有很好的理解。

长话短说…。在与他们一起工作的短短几天里，我发现事情并不像表面上那样。

让我定义一些术语，我将在这里使用知识--一些你在学校、书或互联网上学到的东西。

Experience --你做某事的时间

技能-仅通过经验获得。那就是获得技能(随着时间的推移)，并且知道如何运用你所拥有的知识。

我发现，即使他们知道这些东西，他们也不知道如何运用这些知识。你会有所有这些模式在你面前挥动，但任何他们必须自己写的代码都有基本的缺陷。它们可以告诉您某种设计模式的优点，并可以提出某种实现，但无法识别设计中的基本缺陷。

当然，我在中也有自己的一份，“一个不知道他不知道-Confucius的人”。

每天晚上，我都会花大量的时间重复白天说的每句话，试图理解谁在说什么和为什么，试图通过培训或代码评审期间的例子来找出我能做些什么。但坦率地说，我很困惑。

大约2-3周后，我开始想办法了。总之，首先要问的问题是:你经历过这样的事情吗? 2.你(或你)是如何处理这个问题的？

我的结论是，要么学校做得不好，要么谷歌是他们的朋友，他们得到了所有这些“知识”，并认为自己知道。

但我觉得

1. 为了能够识别和欣赏好的设计，必须编写好的代码，…。设计得不太好。与它斗争，然后修复它，了解它的痛苦，因此认识到好的和坏的设计，欣赏它，
2. 的实践和经验--你就是无法战胜它。经验(以及经验的质量)带来的东西太多了，你只是无法将它与知识或一点点经验相匹配。

我还经历了一些其他的事情：“为什么这是一个接口而不是一个基类”--你会得到各种各样的答案，但它们都不是正确的原因。

为什么这个设计模式，而不是那个，或者忘记设计模式一分钟，只是设计(他们完全迷失了-这是当你看到他们真正的设计编码技能)

在工程上-不认识它，也不能欣赏它们，这可能是一个维护梦魇，因为系统的发展。我觉得这是个大问题。好像一切都有改变的潜力。发送电子邮件的简单过程除了.NET框架中用于发送电子邮件的各种类之外，还有3个类。

使用框架或语言中的所有新特性仅仅是因为(我甚至在某个可用源代码的特定框架的Microsoft源代码中看到了这一点)。

所以10年后，每个编写代码的人都使用所有花哨的框架或语言特性使用所有可能的设计模式来编写代码，这样“遗留”代码就可以很好地编写和设计。还是真的是这样？你认为如何？

有没有人觉得10年后我们就会经历一种不同的烂摊子。它散落在十几个代码文件中，过去是因为现在我们有了类，也就是所谓的松散耦合的代码，但是它只是一种不同的混乱，实际上更难清理？

Answer 1

有趣的讨论。我一直觉得，随着时间的推移，我们的系统工程已经过时，所有的模式都在飞来飞去。一个额外的抽象层意味着未来更多的理解失败。我个人的方法是保持简单，只有在需要时才引入复杂性。如果需要解耦，则解耦。许多设计需求确实在系统中流动，因为我们盲目地将需求文档放在应该是可维护、可靠和所有*的需求文档中。这也是有必要了解的程度，我们希望这些*的，更重要的是，他们如何影响我们的预算和商业价值，无论是在短期和长期。

一个重要的方面是，在每个阶段，无论是在功能上还是在预算上，都要非常专注于业务需求。

Answer 2

我完全同意，新一代开发人员在设计模式和最新流行词汇(如hibernate、jason、nant、ajax等)方面似乎知识渊博。另一方面，我发现，即使是最优秀的开发人员，那些可以被认为是明星程序员的人，对幕后真正发生的事情的理解和知识似乎也很有限。

过去，我和一些年轻人进行了几次交谈，他们把春天看作是一项重大的创新，试图说服他们，这个框架通过反思提供给我们的是IDL、类型库、COM和CORBA等事物的演变。

当谈到设计模式和四人组织引入的术语时，我们都知道，他们提出的体系结构已经使用了几十年，一位高级开发人员几乎凭直觉使用它们，却不知道正规工厂与抽象工厂的形式差异。当然，DP运动引入的正规化对行业是有益的，尽管模式的承认和成功实施仍然(而且可能总是)依赖于开发人员的经验和人才，因为这个过程不可能成为一个纯粹的机械和确定性的过程。

关于SD领域的新手，我还要指出的另一点是，他们倾向于将自己的技能水平地扩展开来，试图涵盖尽可能多的技术，而不是深入地集中于某个特定领域并掌握它。