清除代碼異味

來源:互聯網
上載者:User

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

  為什麼我們需要有品質的代碼?

  • 敏捷開發方法是用來應付那些要求代碼做大量改動的反饋資訊的方法。
  • 如果程式沒有用一種好的表達方式來表現,那程式會很難讀,難維護,難修改。

  什麼是代碼異味?

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

  重複的代碼

  • 會引起程式裡面多個地方相同的錯誤
  • 印度小夥:每兩個月我們都會把這相同的錯誤修改一次
  • 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定律 [不要告訴我,我會通知你]
  • Liskov替換原則
  • 先讓它跑起來,再讓它無誤,再讓它快速
  • 開發/閉合原則
  • 反向依賴
  • 單一責任原則

  一些參考書籍

  • 代碼整潔之道(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?)
  • 關於學習:在使用者組裡跟其它人合作,交流,討論。你並不能學到所有的東西,但要努力縮小自己的“你不知道你不知道的東西”,讓它成為“你知道你不知道的”

轉自 http://justjavac.iteye.com/blog/1073139

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.