做Java的朋友們總想要達到更高的境界，用更少的代碼解決更多的問題，用更清晰的結構為可能的傳承和維護做準備。想想當初自己摸著石頭過河，也看過不少人介紹的學習路線，十多年走過來多少還是有些收穫。現通過自身經歷總結一篇文章，供弟兄們參考。
1、用好正在用的框架
在已經加入的團隊中，和大家協作使用團隊已選好的框架。不管框架優劣與否，特點如何，選擇了它必然有一定的道理。並且能夠在業界經久流行的框架也一定有它的優秀之處。
使用框架第一步是熟悉，可能通過複製和修改前人的代碼來實現新的功能或修改已有功能，逐漸熟悉該框架的使用方法。
第二步是深入瞭解，會用、多用之後，根據用法和現象掌握其規律，從而形成對框架內部結構和運行機制的猜測，大部分肯定都是對的。
第三步是用好，在對框架內部機制有了一定的感覺後，逐漸總結並採用更佳實踐，達到同樣目的採用更簡潔清晰或更高效率的方法。可以參考框架的“最佳實踐”文檔（比如Hibernate參考手冊的最後一章），對沒有提供“最佳實踐”文檔的可以自己總結一些經驗，並不斷完善。
沒有絕對的最佳實踐，只有適應於某一場景的最佳實踐，和適用於大多數場合的較好實現。能夠根據場景選擇不同的模式，是水平提高的標誌。
2、瞭解標準類庫、企業級技術和開源項目
Java界現有的積累已經很豐富，當遇到某個問題感覺它是個普遍問題時，很有可能就已經有現成的標準類庫或開源項目等在那裡了。掌握好標準類庫和開源項目，可以減少工作量，使代碼結構清晰容易理解。企業級技術是指JavaEE平臺內的技術，其多是從已有積累中提煉出的標準，比如JPA就很大程度上來自於Hibernate。企業級技術的運用對程序的標準化很有好處。
對標準類庫和開源項目的瞭解不分先後，可以是交叉進行的，用到了哪個就看看學學哪個。也可以用業餘時間挑自己喜歡的學習學習、做做實驗。
2.1. 標準類庫
從Java自帶的文檔中可以看到標準類庫（以及平臺工具）的列表以及相互關係。下面這幅圖就是層次關係圖：
以挑自己感興趣的點進去詳細瞭解。
乍一看內容眾多，但實際上可能已經有很多已經被用過了。比如JDBC，應該是每個Java程序員在涉世不深時就已經用過的了吧。JNDI應該也是做WEB工程必須接觸的東西。也許只是其中幾個API，不過什麼都是瞭解、熟練、精通這三步，瞭解了，後面就不遠。
其中規則表達式、XML處理、applet、併發（多線程）、網絡、IO、圖形是比較實用的功能，可以先從它們入手。本地接口（JNI）、管理擴展（JMX）、反射等可以用在更高級一些的場合，會了之後可以為更多的場景提供解決方案。
2.2. 企業及技術
包括JavaMail、JMS、EJB、JPA、JSF、web service等，具體的列表可以到JavaEE技術官網找到。這些技術用起來並不深奧，甚至比標準類庫還淺顯。
2.3. 開源項目
框架一般都是開源項目，目前擁有開源項目最多的組織莫過於Apache。可以通過需要來學習開源項目，比方說需要處理Excel文檔，那就去學用POI；要用web service就看看CXF；需要字符串處理就看看Commons Lang中有沒有實現；需要IO操作就看看Commons IO中有沒有實現。
除了Apache，還有eclipse、springsource和Jboss等多家開源機構提供了大量的免費好貨，有時間就去了解一下不失為進階的好手段。“君子性非異也，善假於物也“——厲害的傢伙不一定是什麼都會自己寫，而往往是會結合使用各種神器。
這裡順便說一句，很多開源項目都用了比較少見的英文單詞或是自造詞作為名字，遇到時最好去官網上確定它的讀音。很多人把Struts（原意：大搖大擺）讀成了Structs，明顯跟struct（結構）搞混了，聽起來實在業餘。還有PostgreSQL應讀作postgres-QL，而不是postgre-SQL，請尊重作者的原意。Debian應讀作“戴博伊恩”，是作者夫婦的名字合體，讀成“大便”就太對不起人家了。Ubuntu也別讀“優斑圖”了。
3. 把程序寫得更好
3.1. 代碼格式整潔優雅
儘量遵循官網上的代碼格式建議，善用開發工具（Eclipse）的自動格式化功能。
複雜的條件、循環嵌套提煉為方法，把方法名起得有意義，儘量讓後人看程序就好像看直白的英文句子一樣。追求代碼自我註釋。要注意儘量用單詞別用拼音，特別是模塊之間交互的接口，英語單詞和拼音的混雜使用會讓後人昏死。現在的電子詞典品種繁多、易於使用，善用它們，讓代碼優雅的同時還可以多認識幾個單詞。
3.2. 代碼內容高效
用過很多框架和開源項目並自己寫了不少程序之後，可以開始考慮實踐《Effective Java》中所講的內容，何時何地如何運用合適的技術與機制。
4. 通過標準類庫、企業級技術和開源項目瞭解模式
說到模式大家首先想到的可能是“設計模式”，有很多初學者為了進步也看了《設計模式》這本書，不過據我經驗，當時看不懂，不知道那些模式為何存在，也不知道何時可以用上它們。實際上所謂“模式”不過是前人的習慣用法，被後人認為好用並廣泛流傳。所有將前人代碼複製過來改一改就用的，這樣的代碼其實都可以說是某種“模式”的實現。
有了對標準類庫、企業級技術和一些開源項目的運用後，模式的感覺才會在頭腦中建立。這些類庫、技術、項目本身實現了很多模式，對它們的使用也是模式。只不過後者常被稱為實戰，而並沒有當做“模式”出現在出版物中。
“模式”除了《設計模式》包括《企業應用架構模式》、《J2EE核心模式》，也許還有更多其它的。標準類庫和開源項目（包括很多流行框架），出於設計的靈活性、便捷性、優雅性，對它們有傑出的運用。
Spring就是對工廠模式的實現。JDBC和JMS是對抽象工廠方法模式的實現。
Struts除了大家皆知的MVC，其實還實現了J2EE核心模式中的好幾樣。
Hibernate內部使用了Proxy模式，而它整體的存在是《企業應用架構模式》中“表數據入口”的實現。而老的EJB2.0中的CMB更像是“行數據入口”的實現。
這些模式直接當做概念來學習，沒有實際經驗，就會像我當初一樣不知它們為何存在也不知如何運用它們，事倍功半。
現成的產品用多了就有感覺了。感受它們帶來的方便，將它們中功能相似的互相比較，就可以看得出各種模式的存在和它們的優秀之處了。
5. 瞭解面向對象的真諦
面向對象的八大原則在《敏捷軟件開發——原則、模式與實踐》中有所介紹，其中我最看重“單一職責”原則，這個原則在模塊劃分時很有幫助，其思想甚至可以延伸到組織結構的建設上。
6. 展望——架構師
有了以上幾步，應該就可以作為一個合格的設計人員而存在了。想做到架構師，曾經有位培訓師告訴我們：“學習Linux內核。”
大的步驟是：看0.01版瞭解其結構，看0.10版瞭解其進步，看0.12版瞭解其完善，看最新版瞭解其現狀。
學習方法是使用UML工具，對下載的Linux內核源文件進行反向工程，從得到的類圖中可以看出模塊依賴關係，出度最大的模塊就是系統的核心，從這個模塊看起，看它如何調度其它各個模塊，再去看各模塊如何實現自己的功能。
閱讀更多 杭州華信智原 的文章
