|
|
本文是從 Cleaning up code smells: Venkat Subramaniam @ Chennai 這篇文章翻譯而來。
今天，Venkat Subramaniam 就關(guān)于清除代碼異味的話題給我們做了一個(gè)非常有趣的演講。下面就是我記錄的一些他的話。
為什么我們需要有質(zhì)量的代碼？
- 敏捷開發(fā)方法是用來應(yīng)付那些要求代碼做大量改動(dòng)的反饋信息的方法。
- 如果程序沒有用一種好的表達(dá)方式來表現(xiàn)，那程序會很難讀，難維護(hù)，難修改。
什么是代碼異味？
- 代碼異味是一種由寫的很差的代碼引起的一種有臭味的感覺，一種程序什么地方會有問題的感覺
- 異味更多的是來自一種直覺，而不是一種有據(jù)可查的標(biāo)準(zhǔn)，當(dāng)你看到有味的代碼時(shí)你就“感覺”到了
- 如果你不把異味清除，不久之后你就會習(xí)慣這種氣味，不再對它有察覺
- 用任何語言都能寫出有異味的代碼：即使最簡單安全的語言，你也能做出天才才能想出的蠢事:)
- 我們經(jīng)常會意識不到自己在寫很臭的代碼，經(jīng)常需要外人為我們指出這點(diǎn)
- 邊注：如果你不想刻意去批評某人的程序，不要說“太愚蠢了”，要說“哦，這很有意思…。可有一種更好的方法你知道嗎”
重復(fù)的代碼
- 會引起程序里面多個(gè)地方相同的錯(cuò)誤
- 印度小伙：每兩個(gè)月我們都會把這相同的錯(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)試
- 不可測試
- 難于重用-> 導(dǎo)致程序員從方法的其它地方拷貝粘貼出重復(fù)的代碼
- 復(fù)雜的條件語句-> 挑戰(zhàn)大腦的邏輯分析能力
- 方法長度：組織歸納水平比控制代碼行數(shù)更重要
方法組成模式
- 方法里的所有語句都必須處在同一個(gè)歸納層次上
無用的注釋
- 讓代碼自我表白
- 標(biāo)注為什么這樣，而不是如何這樣
- 對方法表現(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)于繼承
- 在一對一關(guān)系中使用繼承，滿足Liskov替換原則
- 不要用繼承來實(shí)現(xiàn)方法重用
- 重用方法時(shí)，委托是個(gè)更好的選擇
粘手的語言
- 這種語言更容易導(dǎo)致犯錯(cuò)誤
最臭的代碼
- 冗長的類
- 重復(fù)的代碼
- 淘汰的方法
- 不必要的塑型(cast)
- 過度使用設(shè)計(jì)模式
代碼除味
- 代碼復(fù)查！
- 寫出之后盡快進(jìn)行
- 要增量進(jìn)行
- 要復(fù)查測試用例
- 可使用結(jié)對編程
- 但要保持結(jié)對伙伴的經(jīng)常變動(dòng)，否則你會習(xí)慣你的氣味，不再會有察覺
- 結(jié)對伙伴一、兩天調(diào)換一次
一些設(shè)計(jì)原則
一些參考書籍
- 代碼整潔之道(Clean Code)
- 代碼大全(Code Complete) 2
- 程序員修煉之道(The Pragmatic Programmer)
- 敏捷開發(fā)修煉之道(Practices of an Agile Developer)
- Smalltalk Best Practice Patterns
- 實(shí)現(xiàn)模式(Implementation Patterns) (from @protoiyer)
問和答
- 關(guān)于使用代碼檢測工具，例如PMD：這樣的工具非常的有用，它能讓你捕捉到很直接的問題，使你的代碼復(fù)查工作專注于高層面的設(shè)計(jì)原則問題
- 關(guān)于IDE上附加的工具：不要自己去運(yùn)行它們。讓這些工具在后臺自動(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ù)性編程，移動(dòng)設(shè)備編程興趣濃厚
- 關(guān)于著書：長時(shí)間的思考書中的各項(xiàng)主題，多做這方面話題的討論，吸取精華。當(dāng)開始動(dòng)手去寫時(shí)，已經(jīng)胸有成竹，2周內(nèi)把書寫成
- 關(guān)于思考文獻(xiàn)：思考文獻(xiàn)很有用，但你也要多看看批評性的思考性文章，它們是關(guān)于你如何去思考的(double loop learning?)
- 關(guān)于學(xué)習(xí)：在用戶組里跟其它人合作，交流，討論。你并不能學(xué)到所有的東西，但要努力縮小自己的“你不知道你不知道的東西”，讓它成為“你知道你不知道的”
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。
