本文是從 Cleaning up code smells: Venkat Subramaniam @ Chennai 這篇文章翻譯而來。

　　今天，Venkat Subramaniam 就關(guān)于清除代碼異味的話題給我們做了一個非常有趣的演講。下面就是我記錄的一些他的話。

　　為什么我們需要有質(zhì)量的代碼？

• 敏捷開發(fā)方法是用來應(yīng)付那些要求代碼做大量改動的反饋信息的方法。
• 如果程序沒有用一種好的表達(dá)方式來表現(xiàn)，那程序會很難讀，難維護(hù)，難修改。

　　什么是代碼異味？

• 代碼異味是一種由寫的很差的代碼引起的一種有臭味的感覺，一種程序什么地方會有問題的感覺
• 異味更多的是來自一種直覺，而不是一種有據(jù)可查的標(biāo)準(zhǔn)，當(dāng)你看到有味的代碼時你就“感覺”到了
• 如果你不把異味清除，不久之后你就會習(xí)慣這種氣味，不再對它有察覺
• 用任何語言都能寫出有異味的代碼：即使最簡單安全的語言，你也能做出天才才能想出的蠢事:)
• 我們經(jīng)常會意識不到自己在寫很臭的代碼，經(jīng)常需要外人為我們指出這點
  • 邊注：如果你不想刻意去批評某人的程序，不要說“太愚蠢了”，要說“哦，這很有意思…。可有一種更好的方法你知道嗎”

　　重復(fù)的代碼

• 會引起程序里面多個地方相同的錯誤
• 印度小伙：每兩個月我們都會把這相同的錯誤修改一次
• Venkat：你們?nèi)サ袅酥貜?fù)的代碼了嗎？
• 印度小伙：你說的這個方法不錯！

　　不必要的復(fù)雜

• 程序員本質(zhì)上講高興去處理復(fù)雜的問題
• 復(fù)雜最恐怖

　　異常處理

• 問：有什么比一個空的異常捕捉代碼更糟糕的？

  • try{... } catch (Exception e){}

• 答：一個帶有注釋的空異常捕捉代碼！

  • try{... } catch (Exception e){// is this required? }

• Java的異常檢查：好還是不好？
• 如果你不想處理一個異常，就把它傳遞下去
• 如果你想捕捉兩個異常，使用兩個catch代碼，不要只寫一個而用If條件處理

　　Switch語句& 按類型的條件判斷

• Switch語句和按類型的條件判斷通常可以用多形性來代替

　　長方法

• 你不能在一屏上看到整個方法
• 這通常意味著一個方法承擔(dān)這多重任務(wù)
• 難于調(diào)試
• 不可測試
• 難于重用-> 導(dǎo)致程序員從方法的其它地方拷貝粘貼出重復(fù)的代碼
• 復(fù)雜的條件語句-> 挑戰(zhàn)大腦的邏輯分析能力
• 方法長度：組織歸納水平比控制代碼行數(shù)更重要

　　方法組成模式

• 方法里的所有語句都必須處在同一個歸納層次上

　　無用的注釋

• 讓代碼自我表白
• 標(biāo)注為什么這樣，而不是如何這樣
• 對方法表現(xiàn)進(jìn)行描述等于重復(fù)表現(xiàn)
• 這樣的注釋等于重復(fù)寫一遍代碼

  • i += 1 //遞增

• 長方法里用來描述這個方法有不同的功用的注釋
  • 把里面的功能片段提取成小方法& 刪除注釋
• IDE排泄物：IDE自動產(chǎn)生的注釋空白占位符
• 糟糕的注釋通常產(chǎn)生于TDD*
  • *(TDD：Threat driven development，恐嚇驅(qū)動開發(fā))——你應(yīng)該為方法的表象寫注釋，你應(yīng)該為長方法寫注釋，等
• 產(chǎn)品里的注釋：

  • //上帝保佑，我實在不知道這是什么意思

　　變量名稱

• 使用能表意的名稱
• 不要用單個字母做名稱
• 也不要使用太長的名稱

　　繼承

• 繼承更多的是被濫用了
• 組合通常優(yōu)于繼承
• 在一對一關(guān)系中使用繼承，滿足Liskov替換原則
• 不要用繼承來實現(xiàn)方法重用
• 重用方法時，委托是個更好的選擇

　　粘手的語言

• 這種語言更容易導(dǎo)致犯錯誤

　　最臭的代碼

• 冗長的類
• 重復(fù)的代碼
• 淘汰的方法
• 不必要的塑型(cast)
• 過度使用設(shè)計模式

　　代碼除味

• 代碼復(fù)查！
  • 寫出之后盡快進(jìn)行
  • 要增量進(jìn)行
  • 要復(fù)查測試用例
• 可使用結(jié)對編程
  • 但要保持結(jié)對伙伴的經(jīng)常變動，否則你會習(xí)慣你的氣味，不再會有察覺
  • 結(jié)對伙伴一、兩天調(diào)換一次

　　一些設(shè)計原則

• 高聚合
• 低耦合
• Demeter定律 [不要告訴我，我會通知你]
• Liskov替換原則
• 先讓它跑起來，再讓它無誤，再讓它快速
• 開發(fā)/閉合原則
• 反向依賴
• 單一責(zé)任原則

　　一些參考書籍

• 代碼整潔之道(Clean Code)
• 代碼大全(Code Complete) 2
• 程序員修煉之道(The Pragmatic Programmer)
• 敏捷開發(fā)修煉之道(Practices of an Agile Developer)
• Smalltalk Best Practice Patterns
• 實現(xiàn)模式(Implementation Patterns) (from @protoiyer)

　　問和答

• 關(guān)于使用代碼檢測工具，例如PMD：這樣的工具非常的有用，它能讓你捕捉到很直接的問題，使你的代碼復(fù)查工作專注于高層面的設(shè)計原則問題
• 關(guān)于IDE上附加的工具：不要自己去運行它們。讓這些工具在后臺自動的運行(或智能化)
• 動態(tài)語言里需要重構(gòu)嗎：動態(tài)語言里沒有太多的自動重構(gòu)工具，但程序員仍然應(yīng)該手動的重構(gòu)
• 關(guān)于動態(tài)語言的設(shè)計模式：每種語言都有自己的模式和特色。例如：smalltalk的execute around method模式
• 關(guān)于掌握多種語言
  • 你應(yīng)該知道處理一個問題的多種范式，多種風(fēng)格和多種方式
  • 一種語言中學(xué)到的特色方法應(yīng)用到其它語言里
  • 知道各種不同方式的各自風(fēng)險
• 關(guān)于編程語言趨勢：對函數(shù)性編程，移動設(shè)備編程興趣濃厚
• 關(guān)于著書：長時間的思考書中的各項主題，多做這方面話題的討論，吸取精華。當(dāng)開始動手去寫時，已經(jīng)胸有成竹，2周內(nèi)把書寫成
• 關(guān)于思考文獻(xiàn)：思考文獻(xiàn)很有用，但你也要多看看批評性的思考性文章，它們是關(guān)于你如何去思考的(double loop learning?)
• 關(guān)于學(xué)習(xí)：在用戶組里跟其它人合作，交流，討論。你并不能學(xué)到所有的東西，但要努力縮小自己的“你不知道你不知道的東西”，讓它成為“你知道你不知道的”

it知識庫：清除代碼異味，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。