AJPFX淺談Java新手問題之缺乏良好的編程習慣

★隨意地命名

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

★習慣於代碼的 copy & paste

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

★Magic Number 滿天飛

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

★代碼耦合度太大

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

★被 GC 寵壞

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