Shi*_*mar 6 oop design-patterns
最近刚刚从校外或经过1 - 2年的经验与一群人(来自两家不同的公司)合作,我最初对他们对各种行业流行语和设计模式等的了解印象深刻.此外,他们每个人都有一个对OO设计原理和界面使用有很好的理解.
简而言之...... 在与他们合作的短短几天内,我发现事情并非像他们出现的那样.
让我来定义一些我将在这里使用的术语 知识 - 你在学校或书本或互联网上学到的东西等.
经验 - 你做某事的时间
技能 - 只有经验才能获得.这是获取技能(随着时间的推移)并知道如何应用你拥有的知识
我发现即使他们知道这些东西,他们也真的不知道如何应用这些知识.你将所有这些模式挥舞在你的脸上,但他们必须自己编写的任何代码都有它的基本缺陷.他们可以告诉你某种设计模式的优点,并且可以提出一些实现,但无法识别设计中的基本缺陷.
当然,我有一份"我不知道他不知道的人 - 孔子 ".
每天晚上我都会花很多时间重复一遍白天所说的一切,试图了解谁在说什么和为什么,试图在训练或代码审查期间通过例子来弄清楚我能做些什么.但坦率地说,我很困惑.
大约2-3周后,我开始明白这一点.无论如何,问题首先1.你有没有经历过这样的事情？你是(或者你)是如何解决这个问题的？
我的结论是,要么学校做得不好,要么谷歌是他们的朋友,他们得到所有这些"知识"并认为他们知道.
但我觉得
为了能够识别和欣赏好的设计,我必须编写好的代码,......设计不是很好.与它斗争然后修复它以了解疼痛,因此认识到好的和坏的设计并欣赏它
实践和经验 - 你无法击败它.经验(以及经验的质量)带来了很多,你只是无法与知识或一点经验相匹配.
我经历过的其他一些事情:"为什么这是一个界面而不是基类" - 你会得到各种答案,但没有一个是正确的理由.
为什么这个设计模式而不是那个,或者忘记设计模式一分钟而只是设计(它们完全丢失 - 当你看到他们真正的设计编码技巧时)
过度工程 - 不认识它,也无法理解它们随着系统的发展可能成为维护的噩梦.我发现这是一个大问题.就好像一切都有可能改变一样.除了用于发送电子邮件的.NET框架中的各种类之外,发送电子邮件的简单过程还有3个类.
使用框架或语言中的所有新功能只是因为(我甚至在某些Microsoft源代码中看到了这个源代码可用的特定框架)
所以10年后,每个编写代码的人都会使用所有可能的设计模式使用所有花哨的框架或语言功能来编写它,这样"遗留"代码编写得很好并且设计得很好.或者是吗？你怎么看？
有没有人觉得从现在起10年后我们只会转移到另一种不同的粪便.Muck是分散在十几个代码文件中然后它曾经是因为现在我们已经有了类和所谓的松散耦合代码,但它只是一种不同的混乱,实际上更难清理？
有趣的审议。我一直觉得，随着时间的推移，我们的系统设计过度了，所有的模式都在飞来飞去。额外的抽象层意味着未来更多的理解失败。我个人的方法是让事情保持简单，只在需要时引入复杂性。如果需要解耦，则解耦。许多设计需求确实在系统中流动，因为我们盲目地将其放入需求文档中，认为它应该是可维护的、可靠的和所有可用的。还有必要了解我们对这些能力的需求程度，更重要的是它们如何在短期和长期影响我们的预算和业务价值。
一个重要的方面是始终密切关注每个阶段的业务需求，无论是在功能还是预算方面。