如今所有的Opening，只要有点底气，都会要求candidate有OOD的能力、熟练运用各种设计模式。然而在笔试及面试中，却只能通过形如，“列举GoF书中你知道的设计模式”，“画出strategy模式的UML图”之类的问题来进行测试，在如今实习生都把GoF书翻烂的年代，这样的问题如同，“请说出final, finally, finalize的区别”一样，只能浪费双方的时间。综观面试经验，对于“阐述一下你对OOD的看法”的回答，无非两类：“封装、多态、继承”或者“GoF的模式”，这样的回答恰恰代表了候选人对OOD理解的层次。

在OOD这个domain里面，类比数学公理，我认为Robert.C.Martin的OOD Principles已经说的非常清楚，当中最为核心的一条，就是SRP。所有其他的编程原则如同在五大Principles中的OCP、DIP更多的是基于SRP的一些推论，更不必说DRY原则等等一系列五花八门，变化多端的buzz word。我认为所有的程序设计工作，其实最终的目标都是为了达到隔离关注，将特定的需求交给专门的组件去完成。这里的组件在不同的上下文中含义不同，小至在单个系统模块内部，组件指的可能就是完成特定功能的Class/Function，大至SOA(另外一个buzz word)中，组件指的可能就是某个业务域服务系统。当明确了SRP是终极目标之后，OCP说的，只不过是“部分特定条件下的情况已经被本组件解决完毕并隔离，如需要处理其他特殊逻辑，请通过扩展的方式在特定的地方完成”；DIP则说“本实现所依赖的组件的具体实现选择过程应该由专门的选择策略组件完成，本类的主要关注是利用这些依赖完成本类所标称需要解决的问题”；至于那个DRY原则，则更显浅易懂了，本来就已经有特定的组件把特定的关注解决掉了，还有必要重新解决一次么？
那么所谓的封装、多态、继承，甚至是GoF的各种模式，到底是什么呢？同样的，类比数学中的概念，它们就是一些基于数学公理的推论，虽然我们可以通过公理一步一步的将所有的定理推论都推理出来，但极少数人会在实际运用计算的时候这么做，因为太慢了。同样的，这些类似Best practice的东西的价值也仅仅在于，解决某一特定前提下的某一特定问题，这样，你就明白为什么我深恶痛绝模式驱动编程：模式是为了解决特定问题而产生的，但这帮人的做法是为了运用某种模式，而去创造该模式所符合的问题，这让我想起那个关于数学家的笑话。然而我经历的团队中，这样的情况屡屡发生，成为过度工程的头号原因。
之前经常有人问，如何锻炼设计能力？我就会建议他们看一下那几个principles，每天读，读通读透，让它们成为你的条件反射。在做设计和review设计的时候，不停的问自己，我一共有多少个问题？正在考虑的这个组件要解决什么问题？在它所处的粒度来看，它是否只有单一职责？等到每个问题的答案都是Yes的时候，我认为这个设计至少不差。我之前看到过很多这样的设计，大多数情况下，它们不会有一些fancy的设计模式名称在里头，但却渗透着一股身经百战的老练，比如JQuery的core。
同样的，有一种显而易见的bad smell：当你的代码库中充斥着大量的设计模式名称，而实现代码却看起来极其幼稚（我认为至少得读过Implementation Patterns或者Clean code），那么百分百的，你的团队中就至少有着一个急于想证明自己却又适得其反的成员，该是时候找他谈谈他的定位和成长计划了。

如何用好应届生，是一个相当巨大的管理挑战。如果想要招聘应届生，那么就必须做好心理准备，在很大的概率上，团队将会迎来一个浑浑噩噩的放纵了四年，靠着漏题以及考前突击度过考试的定时炸弹。他们很可能了解除冒泡/交换、晓得一点数组和链表的区别、能讲出进程与线程的轻重之分、目前还有相当大一部分的人基于SSH、JQuery/Ext做过购物车、图书管理系统等东西（感谢培训机构），然而，这样的同学距离一名合格的程序员还差很远。这样的同学很可能只会使用Eclipse的各种包装版（MyEclipse是我见过最多的），但是完全不知道jar/war/ear（Spring一统江湖之后，知道ear的就更少了），不知道javac/jar，从参数传递为止的不同区分POST和GET，离开了JS框架很难发出XHR，更不要说早已被种种框架所屏蔽的大量底层细节（Cookie、Session、JDBC、事务等等）。

当然毕业生里面也有厉害的，比如topcoder component development里面大量在校生，但如果仅仅是抱着希望而去开展校园招聘，那么必然是浪费时间精力的事情。实际上，如何用好应届生，是一个教育问题，而不是管理问题。

作为一个应届生的第一个目标，首先就是成长为一个合格的coder。
所谓合格的coder，是要能清醒的知道，自己写下的每一行代码，到底将会产生什么样的作用。这个方法的语义是什么？他的用户是谁？参数是从何而来的？中间经历了那些处理？可能会有多少个输入的来源？这些不同的来源之间是否有业务上的差异？如果有，我该如何处理？方法的返回值将会被如何使用？我的经验是，只有把这些问题都问完了，有结论了，才会有安全感。
可是，能够问出这样的问题，就要求他心中必须有一个全局的视图。这正是大部分人get lost的地方：过早的关注细节。早早的，这些人就因为这样那样的原因，选定了某个细分小工种，然后对工种以外的知识技能弃之不顾。于是我们见过太多这样的人，身为一个标称的J2EE程序员，毫不羞愧的承认自己不知道如何获取Select控件的值、数据库中表和索引是如何存储的。或者你可以说这是因为我一直在小公司工作，资源紧缺，职责划分不清造成的。那么，退一万步说，一个合格的coder，至少要知道目前工作的项目是如何集成、部署、运行的。之前我的团队中，总是只有少数几个人能成功的完成集成部署，而这些人恰恰又正是能在系统分析、设计阶段提出自己想法的人。对于至今不懂的如何集成部署的人，我想问：一堆不能运行的代码，到底能为你的用户递交什么价值？
除了有全局观，第二个要素就是追求。是的，如果没有追求与那份狂热，你是永远无法成为Jamie Zawinski这样的人（他在Netscape时写的日记）。有了这份狂热，精益求精，或者精益说的Continuous Improvement就已经成为了你的本能，在做何事情的时候，你都在思考，什么东西通过哪种方式，可以变得更好。于是，在不知不觉中，每分钟你都在做各种refactor or even re-design的方案，思考权衡各种利弊，慢慢的你和那种工作八小时内闲着无聊上上网的普通程序员拉开距离了。

各位广大的应届生，你们最大的优势在于，充满着无限可能。越早的开始你的一万小时，就越早到达终点。