今天，Venkat Subramaniam 就關於清除程式碼異味的話題給我們做了一個非常有趣的演講。下面就是我記錄的一些他的話。
為什麼我們需要有質量的程式碼？
- 敏捷開發方法是用來應付那些要求程式碼做大量改動的反饋資訊的方法。
- 如果程式沒有用一種好的表達方式來表現，那程式會很難讀，難維護，難修改。
什麼是程式碼異味？
- 程式碼異味是一種由寫的很差的程式碼引起的一種有臭味的感覺，一種程式什麼地方會有問題的感覺
- 異味更多的是來自一種直覺，而不是一種有據可查的標準，當你看到有味的程式碼時你就“感覺”到了
- 如果你不把異味清除，不久之後你就會習慣這種氣味，不再對它有察覺
- 用任何語言都能寫出有異味的程式碼：即使最簡單安全的語言，你也能做出天才才能想出的蠢事:)
- 我們經常會意識不到自己在寫很臭的程式碼，經常需要外人為我們指出這點
- 邊注：如果你不想刻意去批評某人的程式，不要說“太愚蠢了”，要說“哦，這很有意思…。可有一種更好的方法你知道嗎”
重複的程式碼
- 會引起程式裡面多個地方相同的錯誤
- 印度小夥：每兩個月我們都會把這相同的錯誤修改一次
- Venkat：你們去掉了重複的程式碼了嗎？
- 印度小夥：你說的這個方法不錯！
不必要的複雜
- 程式設計師本質上講高興去處理複雜的問題
- 複雜最恐怖
異常處理
- 問：有什麼比一個空的異常捕捉程式碼更糟糕的？
-
1try { ... } catch (Exception e) { }
-
- 答：一個帶有註釋的空異常捕捉程式碼！
-
1try { ... } catch (Exception e) { // is this required? }
-
- Java的異常檢查：好還是不好？
- 如果你不想處理一個異常，就把它傳遞下去
- 如果你想捕捉兩個異常，使用兩個catch程式碼，不要只寫一個而用If條件處理
Switch語句 & 按型別的條件判斷
- Switch語句和按型別的條件判斷通常可以用多型來代替
長方法
- 你不能在一屏上看到整個方法
- 這通常意味著一個方法承擔這多重任務
- 難於除錯
- 不可測試
- 難於重用 -> 導致程式設計師從方法的其它地方拷貝貼上出重複的程式碼
- 複雜的條件語句 -> 挑戰大腦的邏輯分析能力
- 方法長度：組織歸納水平比控制程式碼行數更重要
方法組成模式
- 方法裡的所有語句都必須處在同一個歸納層次上
無用的註釋
- 讓程式碼自我表白
- 標註為什麼這樣，而不是如何這樣
- 對方法表現進行描述等於重複表現
- 這樣的註釋等於重複寫一遍程式碼
-
1i += 1 // 遞增
-
- 長方法裡用來描述這個方法有不同的功用的註釋
- 把裡面的功能片段提取成小方法 & 刪除註釋
- IDE排洩物：IDE自動產生的註釋空白佔位符
- 糟糕的註釋通常產生於TDD*
- * (TDD：Threat driven development，恐嚇驅動開發)—— 你應該為方法的表象寫註釋，你應該為長方法寫註釋，等
- 產品裡的註釋：
-
1// 上帝保佑，我實在不知道這是什麼意思
-
變數名稱
- 使用能表意的名稱
- 不要用單個字母做名稱
- 也不要使用太長的名稱
繼承
- 繼承更多的是被濫用了
- 組合通常優於繼承
- 在一對一關係中使用繼承，滿足Liskov替換原則
- 不要用繼承來實現方法重用
- 重用方法時，委託是個更好的選擇
粘手的語言
- 這種語言更容易導致犯錯誤
最臭的程式碼
- 冗長的類
- 重複的程式碼
- 淘汰的方法
- 不必要的塑型(cast)
- 過度使用設計模式
程式碼除味
- 程式碼複查！
- 寫出之後儘快進行
- 要增量進行
- 要複查測試用例
- 可使用結對程式設計
- 但要保持結對夥伴的經常變動，否則你會習慣你的氣味，不再會有察覺
- 結對夥伴一、兩天調換一次
一些設計原則
一些參考書籍
- 程式碼整潔之道(Clean Code)
- 程式碼大全(Code Complete) 2
- 程式設計師修煉之道(The Pragmatic Programmer)
- 敏捷開發修煉之道(Practices of an Agile Developer)
- Smalltalk Best Practice Patterns
- 實現模式(Implementation Patterns) (from @protoiyer)
問和答
- 關於使用程式碼檢測工具，例如PMD：這樣的工具非常的有用，它能讓你捕捉到很直接的問題，使你的程式碼複查工作專注於高層面的設計原則問題
- 關於IDE上附加的工具：不要自己去執行它們。讓這些工具在後臺自動的執行(或智慧化)
- 動態語言裡需要重構嗎：動態語言裡沒有太多的自動重構工具，但程式設計師仍然應該手動的重構
- 關於動態語言的設計模式：每種語言都有自己的模式和特色。例如：smalltalk的execute around method模式
- 關於掌握多種語言
- 你應該知道處理一個問題的多種正規化，多種風格和多種方式
- 一種語言中學到的特色方法應用到其它語言裡
- 知道各種不同方式的各自風險
- 關於程式語言趨勢：對函式性程式設計，移動裝置程式設計興趣濃厚
- 關於著書：長時間的思考書中的各項主題，多做這方面話題的討論，吸取精華。當開始動手去寫時，已經胸有成竹，2周內把書寫成
- 關於思考文獻：思考文獻很有用，但你也要多看看批評性的思考性文章，它們是關於你如何去思考的(double loop learning?)
- 關於學習：在使用者組裡跟其它人合作，交流，討論。你並不能學到所有的東西，但要努力縮小自己的“你不知道你不知道的東西”，讓它成為“你知道你不知道的”
原文：tools for agile 譯文：外刊IT評論