代碼重構之談

何謂重構

• 重構是：
  • 爲了是代碼更易於維護和修改，在一系列小的、語義不變的代碼轉換（便是代碼保持正常工做）中重組、重排代碼。
• 重構不僅是任意的調整
  • 代碼必須仍能正常工做
  • 小步驟僅使語義被保留（即不是一個重大改寫）
  • 單元測試來證實代碼仍然有效
  • 代碼是
    • 更鬆散的耦合性
    • 功能更彙集的模塊
    • 更容易理解的
• 有不少人所共知的重構技術
  • 你至少應該在Do yourself以前，多多少少熟悉一些
  • 設計重構「條款」

什麼時候重構

• 你應該重構：
  • 當你看到一個更好的方式來來作同一件事的任什麼時候候
    • 「更好」意味着使代碼在未來更易於理解和修改
  • 只要不破壞現有代碼你均可以這樣作
    • 注意此時的單元測試很重要
• 你不該該重構：
  • 並不須要修改的穩定代碼，
  • 別人的代碼
    • 除非對方贊成，或它屬於你
    • 在敏捷開發中這不是問題，由於代碼都是公共的

重構環境

• 傳統的軟件工程以後仿照傳統
  • 工程實踐（= 先設計，而後寫代碼）
• 假設：
  • 預期的最終產品可提早肯定
  • 給定類型（水管工，電工等）的工人是能夠互換的
• 敏捷軟件開發是基於不一樣的假設：
  • 隨着用戶對軟件的認知，需求（也有設計）不斷變化
  • 程序員是具備不一樣技能和知識的專業人士
  • 程序員位於做出設計決策的最佳位置
• 重構是敏捷開發的基石
  • 當發現設計有缺陷時，傳統工程也是須要重構的

重構起源何處

• Ward Cunningham和Kent Beck，Smalltalk裏有影響力的專家
• Kent Beck，極限編程的領導者
• Ralph Johnson，伊利諾伊大學教授，「Gang of Four」之一
• Bill Opdyke，Ralph的博士生
• Martin Fowler，http://www.refactoring.com/
  • 重構：改善現有代碼的設計

再談重構

• 什麼時候你應該重構
  • 任什麼時候候，只要你發現能夠改進現有代碼的設計
  • 當你在代碼中發現了「壞味道」（有跡象代表有些什麼東西是錯誤的）
• 什麼時候你能夠重構
  • 你應該在一個有利的環境中（敏捷開發團隊，或作你本身的工做）
  • 你熟悉經常使用的重構技巧
  • 有幫助的重構工具
  • 你應該有足夠的單元測試集

重構過程

• 作一個小變化
  • 一個單一的重構
• 運行全部的測試，以確保一切仍然工做
• 若是一切正常，就進行下一個重構
• 若是沒有，修正問題，或撤消更改， 這樣才能保證始終有一個能正常工做的系統

代碼的味道

• 若是太臭，改變它
  • 代碼可使設計更加難以改變
• 好比：
  • 重複的代碼
  • 長方法
  • 巨類
  • 巨大的switch語句
  • 長的級聯調用（例如：a.b().c().d()）
  • 大量的檢查null對象
  • 數據簇（例如，一個聯繫人Contact類有地址、電話、Email屬性等）—相似於關係設計中非規範化的表
  • 數據類（主要有字段/屬性，不多甚至沒有方法）
  • 未封裝的數據字段（public的成員變量）

本文翻譯自： http://www.math.uaa.alaska.edu/~afkjm/csce401/handouts/refactoring.pdf