搞Java的程序員肯定都想要達到更高的境界，用更少的代碼解決更多的問題，用更清晰的結構為可能的傳承和維護做準備。想想當初自己摸著石頭過河，也看過不少人介紹的學習路線，十多年走過來多少還是有些收獲。現通這篇Java高級架構師多年的職場心得級規劃的文章，供程序員們參考。

　　用好正在用的框架

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

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

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

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

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

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

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

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

　　標準類庫

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

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

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

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

　　企業及技術

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

　　開源項目

　　框架一般都是開源項目，目前擁有開源項目最多的組織莫過于Apache。可以通過需要來學習開源項目，比方說需要處理Excel文檔，那就去學用POI；要用webservice就看看CXF；需要字符串處理就看看CommonsLang中有沒有實現；需要IO操作就看看CommonsIO中有沒有實現。

　　除了Apache，還有eclipse、springsource和Jboss等多家開源機構提供了大量的免費好貨，有時間就去了解一下不失為進階的好手段。“君子性非異也，善假于物也“——厲害的家伙不一定是什么都會自己寫，而往往是會結合使用各種神器。

　　把程序寫得更好

　　代碼格式整潔優雅

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

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

　　代碼內容高效

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

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

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

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

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

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

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

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

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

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

　　了解面向對象的真諦

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

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

　　展望——架構師

　　架構師是一個既需要掌控整體又需要洞悉局部瓶頸并依據具體的業務場景給出解決方案的團隊領導型人物。一個架構師得需要足夠的想像力,能把各種目標需求進行不同維度的擴展，為目標客戶提供更為全面的需求清單。

　　架構師在軟件開發的整個過程中起著很重要的作用。

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

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

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