如今所有的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的方案，思考權衡各種利弊，慢慢的你和那種工作八小時內閑著無聊上上網的普通程序員拉開距離了。

各位廣大的應屆生，你們最大的優勢在于，充滿著無限可能。越早的開始你的一萬小時，就越早到達終點。