最近刚刚在校外或者有1 - 2年的经验与一群人（来自两家不同的公司）合作，我最初对他们对各种行业流行语和设计模式等的了解印象深刻。此外，他们每个人都对OO的设计原则和界面的使用有很好的理解。
长话短说....在与他们合作的短短几天内，我发现事情并非像他们出现的那样。
让我来定义一些我将在这里使用的术语 知识 - 您在学校，书本或互联网等方面学到的东西。
经验 - 您做某事的时间
技能 - 仅通过经验获得。这是获取技能（随着时间的推移）并知道如何应用你拥有的知识
我发现即使他们知道这些东西，他们也真的不知道如何应用这些知识。你将所有这些模式挥舞在你的脸上，但他们必须自己编写的任何代码都有它的基本缺陷。他们可以告诉你某种设计模式的优点，并且可以提出一些实现，但无法识别设计中的基本缺陷。
当然，我得到了 “一个不知道他不知道-Confucius ”的人。
每天晚上我都会花很多时间重复一遍白天所说的一切，试图了解谁在说什么和为什么，试图在训练或代码审查期间通过示例来弄清楚我能做些什么。但坦率地说，我很困惑。
大约2-3周后，我开始明白这一点。 无论如何，问题首先 你有这种经历吗？ 你是怎么（或者你）解决这个问题的？
我的结论是，无论是学校做得不好还是谷歌都是他们的朋友，他们都得到了所有这些“知识”，并认为他们知道。
但我觉得
为了能够识别和欣赏好的设计，我必须编写好的代码，......设计不是很好。与它斗争，然后修复它以了解疼痛，因此认识到好的和坏的设计并欣赏它
实践和经验 - 你无法击败它。经验（以及经验的质量）带来了很多，你只是无法与知识或一点经验相匹配。
我经历的其他一些事情： “为什么这是一个接口，而不是基类” - 你会得到各种答案，但没有一个是正确的理由。
为什么这个设计模式而不是那个，或者忘记设计模式一分钟而只是设计（它们完全丢失 - 就在你看到它们真正的设计编码技巧时）
过度工程 - 不认识它，也无法理解它们随着系统的发展而成为维护的噩梦。我发现这是一个大问题。就好像一切都有可能改变一样。发送电子邮件的简单过程除了用于发送电子邮件的.NET框架中的各种类外，还有3个类。
使用框架或语言中的所有新功能只是因为（我在某些Microsoft源代码中已经看到了某个源代码可用的特定框架）
所以10年后，每个编写代码的人都在使用所有可能的设计模式使用所有花哨的框架或语言功能来编写代码，这样“遗留”代码编写得很好并且设计得很好。或者是吗？你觉得怎么样？
有没有人觉得从现在起10年后我们只会转移到另一种不同的粪便。 Muck是分散在十几个代码文件中然后它曾经是因为现在我们已经有了类和所谓的松散耦合代码，但它只是一种不同的混乱，实际上更难清理？
答案 0 :(得分：1)
有趣的审议。我一直觉得，随着时间的推移，我们正在设计我们的系统，所有的模式都在飞来飞去。额外的抽象层意味着将来更难理解。我个人的方法是保持简单，只在需要时才引入复杂性。如果需要去耦，则去耦。许多设计要求确实在系统中流动，因为我们盲目地在需求文档中提出它应该是可维护的，可靠的和全部的。我们还需要了解我们希望这些* ables的程度，更重要的是了解它们在短期和长期内如何影响我们的预算和业务价值。
在功能和预算方面，一个重要方面始终是在每个阶段都非常关注业务需求。
答案 1 :(得分：1)
我完全同意新一代开发人员在设计模式和最新的流行语如hibernate，jason，nant，ajax等方面似乎非常了解。另一方面，我发现即使是最好的那些可以被视为明星程序员的人似乎对真正发生的事情的理解和知识有限。
我过去曾与年轻的枪手进行了几次对话，他们认为春天是一项重大的创新，试图说服他们这个框架通过反思为我们提供的东西包括IDL，类型库，COM和CORBA等东西的演变。当涉及设计模式和四人一组引入的术语时，我们都知道他们提出的架构已经使用了几十年，而且高级开发人员几乎直观地使用它们而不知道正规工厂的正式差异与摘要。毫无疑问，DP运动引入的形式化对行业有利，尽管模式的认可和成功实施仍然（并且可能总是）依赖于开发人员的经验和才能，因为这个过程是不可能的成为一个纯粹机械和确定性的。
对于SD领域的新人，我必须做的另一点是他们倾向于非常横向地传播他们的技能，试图涵盖尽可能多的技术，而不是深入专注于特定领域并掌握它。