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

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

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

　　什么是代碼異味？

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

　　賽爾號(hào)里的麗莎布布配招重復(fù)的代碼

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

　　不必要的復(fù)雜

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

　　異常處理

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

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

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

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

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

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

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

　　長方法

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

　　方法組成模式

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

　　無用的注釋

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

  • i += 1 //遞增

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

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

　　變量名稱

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

　　繼承

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

　　粘手的語言

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

　　最臭的代碼

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

　　代碼除味

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

　　一些設(shè)計(jì)原則

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

　　一些參考書籍

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

　　問和答

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