Java 新手的通病

一：對算法和數據結構不熟悉

　　爲何我先拿「數據結構和算法」說事捏？這玩意是寫程序最最基本的東東。無論你使用 Java 仍是其它的什麼語言，都離不開它。並且這玩意是跨語言的，學好以後無論在哪門語言中都能用得上。

　　既然「數據結構和算法」這麼重要，爲何不少 Java 新手卻很不熟悉捏？我琢磨了一下，估計有兩種可能。有些人雖然是計算機系畢業的，可是當初壓根沒好好學過這門課程，到工做時早都還給老師了；還有一些人是中途轉行幹編程，轉行後又沒有好好地打基礎（都期望速成）。
　　下面我列出幾個很基本的問題，若是你每個問題都搞得很清楚，那說明你過了這關，能夠去看看下一個帖子了。不然的話，你趕忙去找本算法和數據結構的書惡補一下吧。

★何時該用數組型容器、何時該用鏈表型容器？
★什麼是散列函數？HashMap 的實現原理是什麼？
★什麼是遞歸？若是你之前歷來沒寫過遞歸函數，嘗試着寫一個（好比用遞歸函數進行目錄樹遍歷）。
★什麼是算法複雜度？
★你是否理解空間換時間的思想？
★寫一個針對整數數組的冒泡排序函數，看看你要修改幾回才能跑通。
★寫一個針對整數數組的二分查找函數，看看你要修改幾回才能跑通。

 

二：缺少面向對象的基本功

　　按理說 Java 是一個很 OO 的語言，Java 社區也一貫是充滿了「對象」的氛圍。但俺在面試 Java 程序員時，卻屢屢碰到使人大跌眼鏡的事情。俺碰到不止一個求職者，連什麼是「多態」都講不清楚。不少人號稱用過設計模式，但一半以上都僅限於單鍵模式和抽象工廠模式。當我深刻問他/她抽象工廠模式到底有什麼好處時，不少人語焉不詳。

　　爲何不少 Java 程序員會缺少面向對象基本功？這得怪那些 Java 框架。如今 Java 的各類框架太發達、太傻瓜化了，致使不少程序員只須要循序漸進、照着框架進行代碼填空，基本已經喪失了 OOA 和 OOD 的能力。我手下有些個 Java 程序員，對 Spring、Hibernate 等框架了如指掌；但若是給他一個簡單需求，讓他寫一個脫離 Web 框架的獨立 Application，他就不知所措了。這樣的開發人員，未來只能成爲所謂的「軟件藍領」，崗位很可貴到提高。

　　同上面同樣，我此次也提以下幾個問題：
★基於接口的繼承和基於實現的繼承各有什麼優缺點？
★繼承（包括 extend 和 implement）有什麼【缺點】？
★多態（polymorphism）有什麼【缺點】？
★爲何 Java 能夠多繼承 interface，而不能夠多繼承 class？
★假如讓你寫一個小遊戲（好比人機對戰的五子棋），你會如何設計類結構？
★類結構設計時，如何考慮可擴展性？

　　若是上述這些問題你都可以搞得比較清楚，說明你的 OO 基礎還過得去。不然的話，我建議你一邊找些  OOAD 和設計模式的書看看，同時本身動手寫些簡單的小程序（不依賴那些框架），把學到的模式理論結合到實踐中。經過這種方式來提升本身 OOAD 的能力，效果會比較好。

 

三：缺乏良好的編程習慣

★隨意地命名

　　有些新手寫程序，當須要定義某個變量名（也多是函數名、類名、包名等）時，隨意地一敲鍵盤，名字就起好了......若干星期後，碰到某 bug，再來看本身寫的代碼時，心中暗自嘀咕：「這代碼是我寫的嗎？咋都看不懂捏？」
　　因此我常跟新來的菜鳥說，命名不規範害死人啊！鑑於該問題至關廣泛，我整理了幾種典型的做爲反面教材，具體以下：使用單字母命名變量；使用一些沒太大意義的變量名（例如 s一、s二、s3）；對同一個業務概念使用不一樣的術語/縮寫（容易讓讀代碼的人神經分裂）；使用拼音命名（若是你團隊中有港臺人士或者老外，就慘了）。

★習慣於代碼的 copy & paste

　　這是一個很廣泛的問題。不少新手寫代碼的時候，若是發現要寫的某個函數和前幾天寫的某個函數差很少，就把原來的那個函數貼過來，而後稍微改幾下，心中還暗喜：「又快速搞定了一個功能」......
　　同窗，若是你也喜歡這麼幹，可要注意了。這種作法是代碼臭味（借用《重構 - 改善既有代碼的設計》的提法）的主要來源，致使代碼可維護性大大降低。當你未來須要增長功能或修改 bug 的時候，要同時改動多個地方，而那時你估計已經想不起來這砣代碼有幾個克隆了。

★Magic Number 滿天飛

　　若是你沒有據說過「Magic Number」，先看「這裏」瞭解一下。
爲了說明Magic Number的問題，咱找個例子來講事兒：假設有個業務邏輯中須要進行10秒的超時等待，你會怎麼寫這個sleep語句？我估計大部分人不外乎下面三種寫法：
一、直接寫上 sleep(10*1000); 了事
二、定義一個常量 TIMEOUT_XXX = 10*1000; 而後 sleep(TIMEOUT_XXX);
三、在配製文件中加入一個超時項，而後程序讀取配製文件得到超時值，而後調用 sleep。（此處提到的「配置文件」是廣義的，泛指各類可用於存儲配置信息的機制，如：xml 文件、ini 文件、數據庫 ...）
　　若是你的作法相似於寫法1，你多半喜歡隨手硬編碼。硬編碼不光缺少可讀性，並且具備和「代碼拷貝粘貼」相似的代碼臭味（可能會存在多個 Magic Number 克隆），不利於往後維護。
　　至於寫法2，比寫法1稍好（至少可讀性好了）。可是，未來一旦發生需求變動，要求在【運行時】調整超時間隔（甚至要求讓用戶來配製超時間隔），則寫法2的缺點立馬暴露無遺。

★代碼耦合度太大

　　每當說到 MVC 或者設計模式，幾乎每一個 Java 開發人員都能說得頭頭是道？可是說歸說，真正寫代碼的時候，鮮有人寫出的代碼是層次清楚的。至於說到代碼耦合分別由哪些狀況引發？什麼是正交的設計？（關於耦合與正交設計，我後面會專門討論一下）能徹底搞明白的人就更少了。
　　因此不少 Java 新手的代碼耦合度大也就不足爲奇了。我曾經抽查過試用期員工的代碼，各類業務邏輯糾纏在一塊兒，代碼臭味都要薰死人。想重構都無從下手，只好讓他推倒重寫。

★被 GC 寵壞

　　因爲 Java 在語言層面提供了內存的垃圾回收機制，程序員只管申請內存，不須要再關心釋放的問題。所以不少新手養成了壞習慣，對於其它資源（好比數據庫鏈接）也只申請不釋放（有些人甚至天真地覺得 JVM 會幫你搞定資源回收）。
　　還有些人雖然知道資源須要釋放，可是經常忘記（好比寫了打開數據庫鏈接和相關代碼，【即將】寫關閉數據庫鏈接時，忽然有人叫你去吃中飯，回來後就把這茬給忘了）。
　　這個壞習慣會致使資源的泄露，而資源泄露每每比內存泄露更要命。若是你寫的程序是長時間運行的（好比運行在 Web Server 上），時間長了會因爲資源耗盡而致使整個進程出問題。

 

四：異常處理使用不當

★空的 catch 語句塊

　　犯這種錯誤的人比較少，通常發生在剛學會 Java 或者剛參加工做不久的人身上。
　　所謂「空 catch 語句塊」就是在 catch 語句塊中沒有對異常做任何處理（好比記錯誤日誌），致使異常信息被丟棄/忽略。一旦程序不能正確運行，因爲查不到任何 log 信息，只好從頭看代碼，靠肉眼找 bug。

★沒有使用 finally

　　不少人在 catch 語句以後不使用 finally 語句。因爲在 try 語句中可能會涉及資源的申請和釋放。若是在資源申請以後、資源釋放以前拋出異常，就會發生資源泄露。
　　（資源泄露的嚴重性，上面已經聊過了）

★籠統的 catch 語句塊

　　有些人爲了省事，只在本身模塊的最外層代碼包一個 try 語句塊，而後 catch(Exception)。無論捕獲到什麼異常，都做統一 log 了事。這種作法比「空 catch 語句塊」稍好，但因爲不能對具體的異常進行具體處理，對一些可恢復的異常（下面會提到），喪失了恢復的機會。並且也可能致使上述提到的資源泄露的問題。

★使用函數返回值進行錯誤處理

　　有些人放着 Java 的異常機制不用，而用函數返回值來表示成功/失敗（好比：返回 true 表示成功、false 表示失敗），簡直是「捧着金碗要飯」。我的感受，從 C 轉到 Java 的人比較容易有此毛病。這種作法會致使以下幾個問題：
1. 返回值通常用整數值或布爾值表示，傳遞的信息過於簡陋；
2. 一旦調用者忽略了錯誤返回碼，就會致使和「空 catch 語句塊」相似的問題；
2. 對同一個函數的多處調用，都須要對返回值進行重複判斷，致使代碼冗餘（代碼冗餘的壞處，上面也已經聊過了）。

★不清楚「Checked Exception」和「Runtime Exception」的區別

　　這個現象比較廣泛，俺發現不少2年以上 Java 工做經驗的人還沒有徹底搞明白二者的區別。看來這個問題得詳細說一下。
當初Java的設計者有意區分這兩種異常，是別有深意的。其中「Checked Exception」用於表示可恢復的異常（也就是你必須檢查的異常）；而「Runtime Exception」表示不可恢復的異常（也就是運行時異常，主要是程序 bug 和致命錯誤，你【不須要】檢查）。不過這種作法引來了不少爭議（包括不少 Java 大牛），鑑於本帖子主要針對新手，之後再專門來聊這個爭議的話題。
　　爲了便於理解，下面我舉一個例子來講明。假設你要寫一個 Download 函數，根據傳入的 URL（String 參數）返回對應網頁的內容文本。這時候有兩種狀況你須要處理：
1. 若是傳入的 URL 參數是 null，這代表該函數的調用者出 bug 了，而程序自己的 bug 是很難在運行時自我恢復的。這時候 Download 函數必須拋出 Runtime Exception。而且 Download 函數的調用者【不該該】嘗試去處理這個異常，必須讓它【儘早】暴露出來（好比讓 JVM 本身終止運行）。
2. 若是傳入的 URL 參數非 null，可是它包含的字符串不是一個合法的URL格式（可能因爲用戶輸入錯誤致使）。這時候 Download 函數必須拋出 Checked Exception。而且 Download 函數的調用者必須捕獲該異常並進行相應的處理（好比提示用戶從新輸入 URL）。

 

五：不瞭解 JVM

★關於基本類型和引用類型

不少新手不理解Java的基本類型和引用類型在本質上有什麼區別。請看以下的問題：
◇這兩種類型在內存存儲上有什麼區別？
◇這兩種類型在性能上有什麼區別？
◇這兩種類型對於 GC 有什麼區別？
　　關於前兩個問題，請看以前的帖子「Java性能優化[1]：基本類型 vs 引用類型」。

★關於垃圾回收（Garbage Collection）

　　不少新手不理解 GC 的實現機制。請看以下的問題：
◇GC 是如何判斷哪些對象已經失效？
◇GC 對性能會有哪些影響？
◇如何經過 JVM 的參數調優 GC 的性能？
　　關於 GC 的問題，能夠參見以前的帖子「Java性能優化[3]：關於垃圾回收（GC）」。

★關於字符串

　　對於 Java 提供的 String 和 StringBuilder，想必不少人都知道：String 用於常量字符串，StringBuilder 用於可變字符串。那 Java 當初爲何要這樣設計捏？爲啥不用一個類來統一搞定捏？

★關於範型（Generic Programming）

　　從 JDK 1.5開始，Java 引入了一個重量級的語法：範型。不過捏，不少新手僅僅知道範型的皮毛，而對於不少本質的東東，不甚瞭解。
◇GP 是在編譯時實現的仍是在運行時實現的？爲何要這麼實現？
◇GP 的類型擦除機制是咋回事？有啥優勢/缺點？
◇使用範型容器（相對於傳統容器）在性能上有啥影響？爲何？

★關於多線程

　　另外，多線程也是大部分 Java 新手的短板。因此俺最後再來提幾個關於多線程的問題。◇synchronized 關鍵字是怎麼起做用滴？◇synchronized 的顆粒度（或者說做用域）如何？是針對某個類仍是針對某個類對象實例？◇synchronized 對性能有沒有影響？爲何？◇volatile 關鍵字又是派啥用滴？啥時候須要用這個關鍵字捏？