代码改变世界

我的常识——程序员应该“道”“术”双修

2011-11-24 22:16  菜阿彬  阅读(3128)  评论(19编辑  收藏  举报

什么是“道”和“术”

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

  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而已。这个时候才是“技术为我所用”,而不是“我为技术所累”

顺便谈谈面试

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

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

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

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

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

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

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

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

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

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

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

结语

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