1.   引言

搞Java的弟兄們肯定都想要達到更高的境界，用更少的代碼解決更多的問題，用更清晰的結構為可能的傳承和維護做準備。想想當初自己摸著石頭過河，也看過不少人介紹的學習路線，十多年走過來多少還是有些收穫。現通過自身經歷總結一篇文章，供弟兄們參考。

2.   用好正在用的框架

在已經加入的團隊中，和大家協作使用團隊已選好的框架。不管框架優劣與否，特點如何，選擇了它必然有一定的道理。並且能夠在業界經久流行的框架也一定有它的優秀之處。

使用框架第一步是熟悉，可能通過複製和修改前人的代碼來實現新的功能或修改已有功能，逐漸熟悉該框架的使用方法。

第二步是深入瞭解，會用、多用之後，根據用法和現象掌握其規律，從而形成對框架內部結構和運行機制的猜測，大部分肯定都是對的。

第三步是用好，在對框架內部機制有了一定的感覺後，逐漸總結並採用更佳實踐，達到同樣目的採用更簡潔清晰或更高效率的方法。可以參考框架的“最佳實踐”文檔（比如Hibernate參考手冊的最後一章），對沒有提供“最佳實踐”文檔的可以自己總結一些經驗，並不斷完善。

沒有絕對的最佳實踐，只有適應於某一場景的最佳實踐，和適用於大多數場合的較好實現。能夠根據場景選擇不同的模式，是水平提高的標誌。

3.   瞭解標準類庫、企業級技術和開源項目

Java界現有的積累已經很豐富，當遇到某個問題感覺它是個普遍問題時，很有可能就已經有現成的標準類庫或開源項目等在那裡了。掌握好標準類庫和開源項目，可以減少工作量，使代碼結構清晰容易理解。企業級技術是指JavaEE平臺內的技術，其多是從已有積累中提煉出的標準，比如JPA就很大程度上來自於Hibernate。企業級技術的運用對程式的標準化很有好處。

對標準類庫和開源項目的瞭解不分先後，可以是交叉進行的，用到了哪個就看看學學哪個。也可以用業餘時間挑自己喜歡的學習學習、做做實驗。

3.1.  標準類庫

從Java自帶的文檔中可以看到標準類庫（以及平臺工具）的列表以及相互關係。下麵這幅圖就是層次關係圖：

以挑自己感興趣的點進去詳細瞭解。

乍一看內容眾多，但實際上可能已經有很多已經被用過了。比如JDBC，應該是每個Java程式員在涉世不深時就已經用過的了吧。JNDI應該也是做WEB工程必須接觸的東西。也許只是其中幾個API，不過什麼都是瞭解、熟練、精通這三步，瞭解了，後面就不遠。

其中規則表達式、XML處理、applet、併發（多線程）、網路、IO、圖形是比較實用的功能，可以先從它們入手。本地介面（JNI）、管理擴展（JMX）、反射等可以用在更高級一些的場合，會了之後可以為更多的場景提供解決方案。

3.2.  企業級技術

包括JavaMail、JMS、EJB、JPA、JSF、web service等，具體的列表可以到JavaEE技術官網找到。這些技術用起來並不深奧，甚至比標準類庫還淺顯。

3.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也別讀“優斑圖”了。

4.   把程式寫得更好

4.1.  代碼格式整潔優雅

儘量遵循官網上的代碼格式建議，善用開發工具（Eclipse）的自動格式化功能。

複雜的條件、迴圈嵌套提煉為方法，把方法名起得有意義，儘量讓後人看程式就好像看直白的英文句子一樣。追求代碼自我註釋。要註意儘量用單詞別用拼音，特別是模塊之間交互的介面（模塊內部小範圍使用的還好些），英語單詞和拼音的混雜使用會讓後人昏死。現在的電子詞典品種繁多、易於使用，善用它們，讓代碼優雅的同時還可以多認識幾個單詞。

4.2.  代碼內容高效

用過很多框架和開源項目並自己寫了不少程式之後，可以開始考慮實踐《Effective Java》中所講的內容，何時何地如何運用合適的技術與機制。

5.   通過標準類庫、企業級技術和開源項目瞭解模式

說到模式大家首先想到的可能是“設計模式”，有很多初學者為了進步也看了《設計模式》這本書，不過據我經驗，當時看不懂，不知道那些模式為何存在，也不知道何時可以用上它們。實際上所謂“模式”不過是前人的習慣用法，被後人認為好用並廣泛流傳。所有將前人代碼複製過來改一改就用的，這樣的代碼其實都可以說是某種“模式”的實現。

有了對標準類庫、企業級技術和一些開源項目的運用後，模式的感覺才會在頭腦中建立。這些類庫、技術、項目本身實現了很多模式，對它們的使用也是模式。只不過後者常被稱為實戰，而並沒有當做“模式”出現在出版物中。

“模式”除了《設計模式》包括《企業應用架構模式》、《J2EE核心模式》，也許還有更多其它的。標準類庫和開源項目（包括很多流行框架），出於設計的靈活性、便捷性、優雅性，對它們有傑出的運用。

Spring就是對工廠模式的實現。JDBC和JMS是對抽象工廠方法模式的實現。

Struts除了大家皆知的MVC，其實還實現了J2EE核心模式中的好幾樣。

Hibernate內部使用了Proxy模式，而它整體的存在是《企業應用架構模式》中“表數據入口”的實現。而老的EJB2.0中的CMB更像是“行數據入口”的實現。

這些模式直接當做概念來學習，沒有實際經驗，就會像我當初一樣不知它們為何存在也不知如何運用它們，事倍功半。

現成的產品用多了就有感覺了。感受它們帶來的方便，將它們中功能相似的互相比較，就可以看得出各種模式的存在和它們的優秀之處了。

6.   瞭解面向對象的真諦

瞭解了模式，就會發現實現這些模式的根基正是面向對象提供的封裝、多態這些特性，這也是面向對象出現的意義。

面向對象的八大原則在《敏捷軟體開發——原則、模式與實踐》中有所介紹，其中我最看重“單一職責”原則，這個原則在模塊劃分時很有幫助，其思想甚至可以延伸到組織結構的建設上。

7.   展望——架構師

有了以上幾步，應該就可以作為一個合格的設計人員而存在了。想做到架構師，曾經有位培訓師告訴我們：“學習Linux內核。”

大的步驟是：看0.01版瞭解其結構，看0.10版瞭解其進步，看0.12版瞭解其完善，看最新版瞭解其現狀。

學習方法是使用UML工具，對下載的Linux內核源文件進行反向工程，從得到的類圖中可以看出模塊依賴關係，出度最大的模塊就是系統的核心，從這個模塊看起，看它如何調度其它各個模塊，再去看各模塊如何實現自己的功能。

8.   結語

這些步驟並沒有嚴格的界限，可以穿插、迭代地進行。

學習是一個先發散後收斂的過程。開始好像面對一個扇形，越往外走發現不會的越多，需要學的越多。但到了後來就會發現學過的東西相通之處很多，新看的東西能夠快速理解，甚至能夠發現有些東西不過是新瓶裝舊酒，看兩眼就會了。

“愚者察異，智者察同”，愚人看到事物各有不同就覺得世界難以掌握，而智者善於看到事物間的共同點（規律）以使事半功倍。既然程式員都幹得了就別當自己是個愚者。