菜单

程序员应该,精通型程序员的特点

2020年1月12日 - 4166m金沙

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

你知道“有能力”和“熟练”的区别吗?这听起来像一个具有欺骗性的问题,因为两个单词看上去似乎说的是一件事情,但是两者之间的微妙差异却正是关键点。

什么是“道”和“术”

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

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

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

这听起来像一个很难回答的问题,因为这两者似乎意味着同样的事情。但它们之间的微妙区别至关重要。

一个“熟练的”程序员与一个“有能力”的程序员哪个更厉害一些?

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

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

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

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

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

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

有能力”和“熟练的概念

“术”不重要吗?

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

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

《Dreyfus Model of Skill
Acquisition》非常详细地涵盖了这个主题。虽然标题听起来有点学术化,但是论文非常平易近人。

“有能力”的含义是使用足够的经验和知识将事情做完。

顺便谈谈面试

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

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

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

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

“熟练”意味着能够清楚认识到选择某种方式做事的原因以及此种做事的方式是否符合大的框架。

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

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

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

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

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

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

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

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

图片 1

换句话说,一个能够熟练地做某件事情的人总是一个有能力做好这件事情的人,但反过来说可能就不成立了。

结语

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

因此,首先,我们要知道的是,这里胜任的工作定义是“我知道该怎么做”
——虽然过于简化,但非常贴合我们的需要。公平地说,不管你工作在什么样的职业,知道怎么做是非常重要的。如果你是一个程序员,学习该怎么做是你工作的重要部分:

我们首先将“能力”定义为“我知道如何做事”。公平地说,不管你从事何种职业,知道如何做事都是相当重要的。如果你是个程序员,那么你的工作中的很大一部分是学习如何做事。知道如何做事虽然很重要,但是不要只为“知道如何做事”努力,否则你会很快发现自己失业了。

要知道在通向专家道路上,处于中间位置的程序员,都在某个层次止步不前(许多人甚至一辈子都停留在此处):这些上流不属于上流,下流不属于下流的程序员会认为可以用所做事情的多少来区别新手和专家。他们的这种想法其实只对了一半!

不要误会我的意思:知道怎么做,是非常重要的。不要停止去学习怎么做,否则,你很快就会发现自己会失去这份工作。

此处就引出了“熟练”的含义。“熟练”的本质是关于“为什么采用这种方式做事情”——这是理解一个难题的各个部分与理解各个部分如何构成一个整体的难题的不同之处。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图