???????? 最近在做一個(gè)汽車銷售系統(tǒng)的改善工作， 這個(gè)系統(tǒng)已經(jīng)運(yùn)行兩年了， 兩年來， 客戶不斷的提出新需求， 系統(tǒng)也在不斷的改來改去。 這次輪到我來改它了。 ? 想想 N 年前初學(xué)編程的時(shí)候， 書上， 網(wǎng)上， 雜志上不斷的在說， 要養(yǎng)成良好的編程習(xí)慣。 然后還給出了 N 長的一大篇文章來介紹一些編程規(guī)范。 我這個(gè)人是很懶的， 大概的看了一下就過去了。 沒有特意的記什么。 好在我這個(gè)人也不是特別的懶， 對自己的工作也是很上心。 編程的時(shí)候盡可能做到更好。 性能功能能考慮到的都要做到最好。 ? 慢慢的也養(yǎng)成了一些編程的習(xí)慣， ? 時(shí)間長了， 下意識(shí)的就去遵守一些模式，模范之類的東西了。
???????? 有了這些習(xí)慣， 再看這次修改的系統(tǒng)， 真的是生可忍熟不可忍了。 ? 這次我也不說什么編程規(guī)范了， 我就說說這些編程惡習(xí) 。

???????? 一， ? 程序沒有注釋
?????? 注釋 !! 注釋 !!! 如果只是打印了一個(gè) HELLO WORLD ， 您不注釋那也就算了， 如果是只有一兩百行的小功能類您不注釋， 那我也忍了， 可是 3000 多行一個(gè)類的業(yè)務(wù)邏輯代碼， 您老人家還不注釋 !!!?? 你 TM 讓我怎么去改代碼， ? 一點(diǎn)業(yè)務(wù)邏輯的說明都沒有， 我改代碼的時(shí)候，得一邊用 DEBUG 調(diào)試， 一邊替他加注釋。 然后才能進(jìn)行自己的工作。 幾千行的一個(gè)類， ? 一行注釋都沒有， 你 TM 就不覺得顏色單調(diào)了點(diǎn)嗎 ?

?????? 二， ? 不遵守基本的編程約定
?????? 變量名大小寫混亂， 明明是變量， 非要完全大寫， 要不就大寫開頭。 要不就是方法名全是大寫， 最牛 B 的一個(gè)方法是用中文做方法名， 你丫這時(shí)候想起打中文來了， 累不累呀。

?????? 還有人用拼音做變量名方法名，就算您英文不好，稍微查一下金山詞霸行不行，現(xiàn)在百度和 GOOGLE 都有翻譯功能，稍微查一下英文，也當(dāng)是學(xué)英語了行不行？ 您實(shí)在太忙的話，不查也就算了，拼音就拼音吧，好賴也算是中國話的。 可是您就別用拼音簡寫了，英文簡寫還認(rèn)不出來呢， 您還用拼音的開頭字母當(dāng)變量名， 那我 TM 上哪兒猜去呀！

?

?????? 三， 不明就里的代碼

?????? 系統(tǒng)中經(jīng)常會(huì)出現(xiàn)這樣的代碼，尤其是在 controller 里居多：

?????? // some code

?????? If(flag .equals(“submit”)){

?????? model.getInfo();

}else{

?????? model.getInfo();

}

我沒寫錯(cuò)， if 和 else 調(diào)用的方法完全一樣，大家也放心，我仔細(xì)的看過調(diào)用的代碼，調(diào)用的方法里，也沒有根據(jù)其它情況來改變他的運(yùn)行路線。我就不明白為什么要做這個(gè) if 判斷了。擔(dān)心會(huì)有什么特殊的業(yè)務(wù)邏輯， 所以也不趕隨便去改他。 猜了半天，感覺最理想的答案是寫代碼的人，擔(dān)心以后會(huì)有新的邏輯分支， 所以在這里用 if 預(yù)留了一個(gè)位置， 以后改的時(shí)候方便。

數(shù)日之后有幸遇見了當(dāng)初寫這代碼的老兄，問過之后立刻暈倒，原來是這個(gè)代碼是參照別的模塊的樣子寫的，別的模塊在這里都有 N 個(gè)程序分支，通過 if 來判斷后決定調(diào)用哪個(gè) model 里的方法。但他這個(gè)模塊很簡單，沒有什么分支，就是調(diào)用那一個(gè)方法，但他寫代碼時(shí)，看別人的模塊在這里都進(jìn)行 if 判斷了，所以覺得自己也應(yīng)該判斷一下，于是就出現(xiàn)了上面這樣的代碼。

?

四， 面向過程式的編程方法

遇到過好幾次 2000 多行的方法，所有業(yè)務(wù)邏輯，一氣呵成，就用了一個(gè)方法搞定。如果是簡單的邏輯也就算了， 可是幾千行的代碼全放在一個(gè)方法里，一個(gè)類里有無數(shù)的重復(fù)代碼。 這回到好，重構(gòu)那本書沒白看， 現(xiàn)在有了實(shí)踐的機(jī)會(huì)了。

難道您自己調(diào)試的時(shí)候就不覺得麻煩嗎？ 我在這里不想討論什么面向過程還是面向?qū)ο螅矂e和我說什么方法多了也不一定就是面向?qū)ο蟮乃枷搿?/span> 平時(shí)對自己寫的代碼多上點(diǎn)心， 大家都是在這行干了幾年的人了，把代碼寫的漂亮點(diǎn)有什么不好。

?

五， 代碼縮進(jìn)混亂

我們公司有規(guī)定，改代碼的時(shí)候，不許修改原有代碼的格式。 不管他多亂，也不許改。 我不明白這是為什么，也許是檢查代碼的人，要用文件比較工具吧。

但這下苦壞我了， 代碼的格式那叫一個(gè)亂。 有頂著行頭寫的， 有向后空了 N 格的，大概是寫代碼的人， 為了方便自己找到正在調(diào)試的那段代碼，所以把代碼的縮進(jìn)變得和其它代碼與眾不同吧。 那您調(diào)試完了到是重新排一下版呀， 這真的不累～～， 現(xiàn)在的 IDE 工具都有自動(dòng)排版代碼的功能， 一個(gè)快捷鍵就搞定了，稍微勤快一點(diǎn)行嗎？？

最 BT 的一段代碼是縮進(jìn)居然出了屏幕！！！ 你吃飽了撐的呀， 沒事縮那么遠(yuǎn)干嗎， 我根據(jù)后臺(tái)輸出找了半天也沒找到那段代碼在哪兒， 原來是因?yàn)榭s進(jìn)的太遠(yuǎn)了，不在屏幕范圍之內(nèi)， 向右拉了半天滾動(dòng)條才找到。 你丫是不是寫著代碼睡著了？ 臉正好砸在 TAB 鍵上。

?

六， 多余的后臺(tái)輸出

好幾個(gè)循環(huán)嵌套在一起～～～ 也行， 就算是因?yàn)闃I(yè)務(wù)邏輯需要，沒別的辦法也將就了。 好幾個(gè)循環(huán)嵌套在一起查數(shù)據(jù)庫， 咱們最好還是開動(dòng)一下腦筋， 看看有什么更好的辦法。如果還是沒別的辦法， 那也湊合了。 可這種情況您就別在后臺(tái)輸出 SQL 語句啦， 每次一執(zhí)行程序，成百上千個(gè) SQL 語句在后臺(tái)輸出， 查數(shù)據(jù)庫才用了一兩秒，結(jié)果輸出這些 SQL 就用了半分鐘。 您自己就沒覺出程序慢在哪里嗎？ 您調(diào)試程序的時(shí)候輸出一下也就算了， 提交到正式運(yùn)行的環(huán)境時(shí)，就麻煩您，勞您大駕～～ 把那些輸出注釋掉吧，實(shí)在不行留幾個(gè)重要的輸出就行了。 讓這種代碼影響系統(tǒng)性能～～ 也太冤了吧。

?

七， 打腫臉充胖子

我也不知道這條算不算惡習(xí)，也許不算，在有些人眼里還是好事。但也要看具體情況，經(jīng)常有些人寫代碼不喜歡用 IDE ，只用 EDITPLUS 這類工具。按常理說，初學(xué)者都應(yīng)該盡量用這些編輯器寫代碼，對加深學(xué)習(xí)印象有好處。也有人說高手不屑于用那些 IDE ，我少見多怪， 這種絕頂高手我沒見過。

但咱平時(shí)工作的時(shí)候，要的是效率，您不是那種高手就乖乖的用 IDE 吧。經(jīng)常見到有些人，為查一個(gè)方法的調(diào)用，搜來搜去的。真正的高手是工作效率最高的人，不是用最簡單工具的人。

??? 今天就寫這么多， 大家還遇到過什么樣的編程惡習(xí)，歡迎補(bǔ)充。

大家不要總是抱怨什么工資太少，工作量太大。工作效率這玩意兒是要經(jīng)驗(yàn)來做基礎(chǔ)，這沒錯(cuò)，經(jīng)驗(yàn)少也沒事。咱平時(shí)寫程序的時(shí)候多上點(diǎn)心，多對自己的代碼思考一下，多動(dòng)動(dòng)腦子。自然就能總結(jié)出最好的工作經(jīng)驗(yàn)了，工作效率自然就提高了。

也別總是說什么 STRUTS 不好， HIBERNATE 太慢，不屑去用它。人家的程序能在全世界流行，自然有他的過人之處。多讀讀他的代碼，學(xué)習(xí)一下他到底好在哪里，如何才能把這些優(yōu)點(diǎn)應(yīng)用到自己的代碼上。這才是最重要的。

?也許咱們寫不出什么高超的代碼技巧，寫不出什么華麗的算法，但如果能在一些習(xí)慣，細(xì)節(jié)上做到精益求精，那也對得起自己的代碼了。


??? 寫出上面這些代碼的人，如果你的工資真的很少，那我只能惋惜的說一句：你的工資是可憐了點(diǎn)，但看您寫的這代碼，連這點(diǎn)工資都不應(yīng)該給你！！