模式,原则,风格,库,语言功能——这些都是工具。但是,一个真正的精通型程序员会让工具来匹配工作,而不是工作匹配工具。

什么是“道”和“术”

  “术”是工具,“道”是工具背后的理论,想法。举几个例子:

  1,Entity
Framework,Nhibernate,就是“术”,这些工具(框架)背后的ORMapping思想的来源,它要解决的问题,Data
Access Layer在架构中的地位(怎么实现Business Logic
Layer对DAL的解耦),Unit Of Work模式的含义……等等,就是“道”;

  2,Asp.net
MVC框架是“术”,MVC这个Pattern,它跟MVP,MVVM的关系,他们的缘起,来龙去脉,用途与目的,在整个架构中的地位(很多人甚至不知道MVC模式只是展现层的模式)、与其它逻辑层的配合……等等,就是“道”。

所以精通还意味着有整体思维的灵活性。

“术”不重要吗?

  要说明的是,我绝不否认“术”的重要。甚至对于初学者来说,“术”更重要,它是我们赖以生存的东西,并且,它能帮助我们对“道”有更深的理解,或者说,没有经过自己“术”加以验证的“道”,很可能只是“半瓶子水”。古语说“纸上得来终觉浅,绝知此事要躬行”,说的就是这个理。

  “术”很重要,但不能仅止于“术”,应该试图掌握工具背后的东西,如果你知道了ORMapping、DAL那一套,哪天到新公司要用NHibernate,或者要用NoSql,都完全没有障碍,所需要的只是一点点的上手时间和google而已。这个时候才是“技术为我所用”,而不是“我为技术所累”。

我建议阅读原始资源材料以便于能更好地纵观从初学者到专家的历程。在这篇文章中,我将重点放在大多数软件开发人员都会碰到的瓶颈:跨越从胜任到精通的沟壑。

顺便谈谈面试

  我在面试别人时有个基本的原则,除了考察他的学习能力、态度、技术热情、交流能力以外,在技术方面,是比较注重他对“道”的理解的,尤其是招聘Sr.
Developer时。

  也许有人会说,如此强调“道”的作用,是不是太不靠谱了?万一那个人谈起来头头是道,写起代码一无是处,怎么办?其实不会这样,真正对“道”说起来头头是道的人,他对“道”的理解都必须是建立在大量的“术”的经验上的。而且,若要招好的程序员,我一直希望在面试时有“结对编程”的阶段,但同样,在“结对编程”时,我会考察他对代码的理解——可测性,设计思想,做事方式,等等,而不是考察他的代码能不能解决问题(即是“术”)。

  也许又有人说,能解决问题就是王道,不管黑猫白猫,能抓到老鼠就是好猫,能解决问题不就行了吗?对这样的见解我只想说:你愿意做个低级码农我不拦着,你也别拦着我朝高级码农的方向努力。

译文链接:
英文原文:The traits of a proficient
programmer
翻译作者:码农网 – 小峰

设计模式是“道”还是“术”?

  前面已经说了,道术相辅相成。但有时候,甚至很难区分什么是道,什么是术。

  比如,设计模式,这个博客园的长青博文主题,每隔一段时间都会冒出来几篇,它是“道”,还是“术”?

  大概两年前,我拿这个问题问我所在团队的所有同事,他们大部分回答这是“道”。

  我不能说这个答案是错的,四人帮的《设计模式》一书,已成经典,人人必看。甚至去面试时,你不谈点设计模式的东西,你都不好意思说自己是程序员。我就碰到过几次这样的面试者,说实话水平一般,但也一定要说上一点设计模式的东西,来抬高自己的身价。

  现实中也是,很多程序员为了显示自己的“设计能力”,让他写一个功能时,他先想好这边可以用几个“设计模式”?这边来个工厂,那边来个单例(面试时被问到“设计模式”时,最常用的两个必杀答案),再来个访问者模式,成了。——这种使用设计模式的方式错了。

  在真正好的程序员心中,设计模式是“术”,设计模式背后的用意才是“道”。为什么要用某个模式,是为了解决什么问题?紧耦合?可测性差?扩展性差?他们写代码时,心中已无设计模式,用心设计、简单设计;在可测性、可扩展性和复杂程度之间做巧妙的权衡取舍;当他们写完代码,已经不知不觉合理地使用了若干设计模式。——其实我这句话也说错了,代码永远没有“写完”的一天,他们会不断重构它,重构出设计模式,或者重构掉设计模式。

  回头看,如果把设计模式看成“道”,我也不反对,但为什么说前面那种使用设计模式的方式还是错了?因为那是在使用“术”的方式来对待“道”。

这正是精通的来源。并且精通的实质是“为什么你要用某种方式做事”
-——是单独理解问题的每个部件与理解部分是如何融入整体之间的差异。

结语

  “道”“术”双修。就我观察的程序员现状来看,怎么强调“道”都不过分。多用我们聪明的脑袋来领悟“道”吧,把很多“术”的问题交给google。

有能力胜任是指有足够的经验和知识来完成各项工作;精通涉及知道为什么你要用某种方式来做事情,以及如何融入到大局中。换句话说,精通型从业者总是有能力胜任,但反之可能不成立。

“道”和“术”,应该更重视哪个?

  以道统术,以术得道——用浅显的话来说,理论指导实践,实践反过来又会影响和升华理论。我们程序员在学习的过程中,总是需要在“写点代码——领悟一点东西——继续写代码——继续领悟”的一个循环中,这也是一个反馈系统。

  可问题是:太多的程序员“道”与“术”严重偏科,他们热衷于工具的使用,却不知道工具被发明出来是为了解决什么问题的;他们可以用代码解决很多问题,却在解决完之后都不知道真正的问题是什么——这也是此文的目的,我很想对这样的程序员强调“道”的重要性。

  以上面的例子来说,重“术”不重“道”的人,会把Entity
Framework框架,MVC框架用的很熟练,并且也能用它们完成所有的任务,可是,会用的很不好——代码的耦合很高,设计很混乱,代码可读性差,可维护性差,可扩展性差,需求一改,到处都得改,过几个月,连自己都看不懂自己的代码了,有一天若要维护这样的人写的代码,就想骂娘,同时自己不断生产出让别人想骂娘的代码。

  这种人工作5年后出去说自己有5年工作经验,其实只是1年工作经验重复了5遍而已。 

胜任和精通之间的差距可以解释为什么如此多的人想要攀登高层次的编程思想,例如设计模式。

但是,处于两者之间的程序员往往会被卡住(很多因此而裹足不前),而他们被卡住的地方被认为是初学者和专家之间的差别,可以用来衡量你知道多少东西。这里只有一半是正确的,并且它强调的是不那么重要了的一半。

关于精通,一次一步,有很长的路要走。你需要超凡程度的胜任才能够在“懂和会”上脱颖而出——但即使是松散的明白“如何在正确的时间做正确的事情”也会带你走得很远。

你知道有能力胜任和精通之间的区别是什么吗?

  • 解释为什么你想要用某种方式做事的原因推理,不依赖于通用的“最佳做法”或社区准则。单单只在你要解决的当前问题的背景下讨论利弊。

  • 了解的东西越少,了解得越深。然后尝试在不同的上下文中加以应用,看看它们在哪里有效,在哪里无效。从失败中寻找机会来寻求新的工具,可以帮助拓宽你的技能集的工具,但只在你已经确立了明确要求的时候。

  • 寻找其他人“打破规则”并取得成功的范例。偶尔打破自己的一些规则,看看是会伤害你,帮助你,还是没有变化。

  • 挖掘基本的资源,而不仅仅是阅读摘要。这需要更多的时间和精力,但可以帮助你弄清楚基础和技术界限,同时也给你一个机会来生成由核心原则启发的新想法。

  • 澳门新葡亰,深入钻研一个你不熟悉的项目,并且试着不依赖记忆套路、习惯和规则,找到你自己的做事方式。

  • 要求别人解释为什么他们要这样做事,但不要只是接受教条式的推理。要求例子并询问上下文背景,以便于你可以尝试着设身处地地去想。这样做是非常有价值的,因为可以让你看到他们自然习惯中的长处和短处。

  • 挑选少数特定你只是擅长但不精通的技能,然后开发胜任的能力到极致,到几乎偏执的程度。一旦你到达顶峰,检查深刻且高度专业化知识的利弊。

更为重要的是,精通型程序员能够识别正确和错误的设计模式——如果建设概念验证功能,适当代码设计的问题可能就变得无关紧要。如果向初学者解释代码库,精通型开发者可能会坚持着重于代码实际上是做什么的,而不会抛出命名模式,并告诉新手“在问我任何问题之前,先去阅读《Gang
of Four》”。

网站地图xml地图