大牛談代碼異味如何清除
為什么我們需要有質量的代碼?
敏捷開發方法是用來應付那些要求代碼做大量改動的反饋信息的方法。
如果程序沒有用一種好的表達方式來表現，那程序會很難讀，難維護，難修改。
什么是代碼異味?
代碼異味是一種由寫的很差的代碼引起的一種有臭味的感覺，一種程序什么地方會有問題的感覺
異味更多的是來自一種直覺，而不是一種有據可查的標準，當你看到有味的代碼時你就“感覺”到了
如果你不把異味清除，不久之后你就會習慣這種氣味，不再對它有察覺
用任何語言都能寫出有異味的代碼：即使最簡單安全的語言，你也能做出天才才能想出的蠢事:)
我們經常會意識不到自己在寫很臭的代碼，經常需要外人為我們指出這點
邊注：如果你不想刻意去批評某人的程序，不要說“太愚蠢了”，要說“哦，這很有意思…。可有一種更好的方法你知道嗎”
重復的代碼
會引起程序里面多個地方相同的錯誤
印度小伙：每兩個月我們都會把這相同的錯誤修改一次
Venkat：你們去掉了重復的代碼了嗎?
印度小伙：你說的這個方法不錯!
不必要的復雜
程序員本質上講高興去處理復雜的問題
復雜最恐怖
異常處理
問：有什么比一個空的異常捕捉代碼更糟糕的?
try{... } catch (Exception e){}
答：一個帶有注釋的空異常捕捉代碼!
try{... } catch (Exception e){// is this required? }
Java的異常檢查：好還是不好?
如果你不想處理一個異常，就把它傳遞下去
如果你想捕捉兩個異常，使用兩個catch代碼，不要只寫一個而用If條件處理
Switch語句& 按類型的條件判斷
Switch語句和按類型的條件判斷通常可以用多形性來代替
長方法
你不能在一屏上看到整個方法
這通常意味著一個方法承擔這多重任務
難于調試
不可測試
難于重用-> 導致程序員從方法的其它地方拷貝粘貼出重復的代碼
復雜的條件語句-> 挑戰大腦的邏輯分析能力
方法長度：組織歸納水平比控制代碼行數更重要
方法組成模式
方法里的所有語句都必須處在同一個歸納層次上
無用的注釋
讓代碼自我表白
標注為什么這樣，而不是如何這樣
對方法表現進行描述等于重復表現
這樣的注釋等于重復寫一遍代碼
i += 1 //遞增
長方法里用來描述這個方法有不同的功用的注釋
把里面的功能片段提取成小方法& 刪除注釋
IDE排泄物：IDE自動產生的注釋空白占位符
糟糕的注釋通常產生于TDD*
*(TDD：Threat driven development，恐嚇驅動開發)——你應該為方法的表象寫注釋，你應該為長方法寫注釋，等
產品里的注釋：
//上帝保佑，我實在不知道這是什么意思
變量名稱
使用能表意的名稱
不要用單個字母做名稱
也不要使用太長的名稱
繼承
繼承更多的是被濫用了
組合通常優于繼承
在一對一關系中使用繼承，滿足Liskov替換原則
不要用繼承來實現方法重用
重用方法時，委托是個更好的選擇
粘手的語言
這種語言更容易導致犯錯誤
最臭的代碼
冗長的類
重復的代碼
淘汰的方法
不必要的塑型(cast)
過度使用設計模式
代碼除味
代碼復查!
寫出之后盡快進行
要增量進行
要復查測試用例
可使用結對編程
但要保持結對伙伴的經常變動，否則你會習慣你的氣味，不再會有察覺
結對伙伴一、兩天調換一次
一些設計原則
Demeter定律 [不要告訴我，我會通知你]
問和答
關于使用代碼檢測工具，例如PMD：這樣的工具非常的有用，它能讓你捕捉到很直接的問題，使你的代碼復查工作專注于高層面的設計原則問題
關于IDE上附加的工具：不要自己去運行它們。讓這些工具在后臺自動的運行(或智能化)
動態語言里需要重構嗎：動態語言里沒有太多的自動重構工具，但程序員仍然應該手動的重構
關于動態語言的設計模式：每種語言都有自己的模式和特色。例如：smalltalk的execute around method模式
關于掌握多種語言
你應該知道處理一個問題的多種范式，多種風格和多種方式
一種語言中學到的特色方法應用到其它語言里
知道各種不同方式的各自風險
關于編程語言趨勢：對函數性編程，移動設備編程興趣濃厚
關于著書：長時間的思考書中的各項主題，多做這方面話題的討論，吸取精華。當開始動手去寫時，已經胸有成竹，2周內把書寫成
關于思考文獻：思考文獻很有用，但你也要多看看批評性的思考性文章，它們是關于你如何去思考的(double loop learning?)
關于學習：在用戶組里跟其它人合作，交流，討論。你并不能學到所有的東西，但要努力縮小自己的“你不知道你不知道的東西”，讓它成為“你知道你不知道的”
原文鏈接：http://www.aqee.net/2011/05/18/cleaning-up-code-smells/
【編輯推薦】
