跟有经验的优秀程序员一起工作能让你学到很多东西,而其中我感觉最有帮助的一点就是学会了编程中的实用主义。
pragmatic
/pragˈmatɪk/
形容词
- 以一种基于实用性而非理论的灵活的现实的方式处理问题。
有学院背景是件好事,如果没有上过大学,我估计我的程序员仕途未必能赶得上现在的一半。但从另外一方面看,学院理论和市场之间存在阻抗失配,学生离开学校毕业进入职业社会,都带着一种被J2EE洗脑的纯洁的错觉,忘记了很多东西只有亲自动手才能学到——这就是为什么很多自学成才的程序员能够解除束缚,开发出伟大的具有革命性的软件的原因。
我曾经就是这样,我曾经熟记《设计模式》里的各种设计模式,并且试图在任何一个可以用的的地方使用它们。但是,当离开大学,开始在现实世界里编程时,我开始认识到一个事情:做“正确的事情®”并非是总能给你带来成功的途径。以我的观点,能证明这种现象的最大的一个例子就是JavaScript语言:虽然世界上有这么多的好的编程语言,为何一个像JavaScript这样的“四不像”语言会成为最流行和最通用的语言?(这个问题留给大家在评论里讨论,我也许会写一篇关于它的文字:))
回到设计模式的话题:设计模式是对重复出现的问题的好的、可重用的解决方案的范例。很好的东西,不是吗?它们怎么可能变成有害的呢?
问题并不是出在设计模式自身,而是我们的一种不加选择地到处使用它们的强迫症,总以为用了它们才是正确的编程。
这种思维习惯会导致你按图索骥,强行让问题去适应设计模式提供的解决方案,而不是它本该采取的方案,同样也会导致过度技术化和不必要的复杂,这些在将来都会导致项目受挫。
采用实用主义的态度,让设计模式在代码中自然的出现,不需要雕琢。你读过这些设计模式,你知道它们的存在,但你不需要特意的以它们为标准去实现一种解决方案。相反,凭借你的经验,这些模式会在你的代码里天然的形成,并适合你的问题,不带任何束缚。也许你甚至不知道这是什么模式,叫什么,这不重要,但如果你知道,你可以注释一下,这能帮助其他程序员更容易的理解,帮助他们明白你的代码在做什么而不需要阅读整段代码——因为你遵循了一种设计模式。
所以,我认为,懂得和熟悉设计模式很重要——就像是你应该经常去看看别人是如何写代码的,是如何用另一种方式解决问题的——但是,不要强迫在代码中使用它们。顺其自然,keep it simple, stupid®!
境界!
keep it simple
正在学习设计模式,看到好多人都说,不要强制使用。今天又看到一篇。个人感觉这是一个必经的过程,从不熟悉使用—生搬硬套的使用—灵活运用。
未必,至少,我没经历这个过程。
只能用的好,用的秒,才能真正体现出它的价值!
一切都要有起点,记得之前看过篇文章介绍如何读科技书的,大意是说不可细读,但是对于新手来说,一切都应从头做起,熟悉了以后才有资格讲究如何跳出模式,而不是一上手就不以模式为原则。
先入再出,目前处于刚入的阶段
其实很多时候设计模式用不上,思考这个问题的时候也没考虑过要用什么模式(也许有考虑过),解决方案出来了或者做完了才发现,这不就是某某模式么?!我再改规范点!
是这样的,我觉得除了控制反转(基本控制方法)和特殊类的单例模式能在设计之初确定下来,很多东西都属于后期优化方法