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

什么是“道”和“术”

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

　　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。