1. 引言 搞Java的弟兄們肯定都想要達到更高的境界,用更少的代碼解決更多的問題,用更清晰的結構為可能的傳承和維護做準備。想想當初自己摸著石頭過河,也看過不少人介紹的學習路線,十多年走過來多少還是有些收穫。現通過自身經歷總結一篇文章,供弟兄們參考。 2. 用好正在用的框架 在已經加入的團隊中,和大 ...
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. 結語
這些步驟並沒有嚴格的界限,可以穿插、迭代地進行。
學習是一個先發散後收斂的過程。開始好像面對一個扇形,越往外走發現不會的越多,需要學的越多。但到了後來就會發現學過的東西相通之處很多,新看的東西能夠快速理解,甚至能夠發現有些東西不過是新瓶裝舊酒,看兩眼就會了。
“愚者察異,智者察同”,愚人看到事物各有不同就覺得世界難以掌握,而智者善於看到事物間的共同點(規律)以使事半功倍。既然程式員都幹得了就別當自己是個愚者。
一個程式員學習平臺分享給你們,讓你在實踐中積累經驗掌握原理。主要方向是JAVA工程師。如果你想拿高薪,想突破瓶頸,想跟別人競爭能取得優勢的,想進BAT但是有擔心面試不過的,可以加我的Java學習交流群:669823128 。