|
系列博客
1. 改善代碼設計 —— 優化函數的構成(Composing Methods)
2. 改善代碼設計 —— 優化物件之間的特性(Moving Features Between Objects)
3. 改善代碼設計 —— 組織好你的數據(Composing Data)
4. 改善代碼設計 —— 簡化條件表達式(Simplifying Conditional Expressions)
5. 改善代碼設計 —— 簡化函數調用(Making Method Calls Simpler)
6. 改善代碼設計 —— 處理概括關系(Dealing with Generalization)
找出需要重構的地方
最明顯可能需要重構的地方包括: 注釋, 長的方法, 長的類, 長的參數列表. 這些都是很快能看出來的.
注釋 (Comments)
1. 函數中有處注釋在說明下面的一個代碼塊在做什么事情, 通常采用 Extract Method 將這些代碼放到一個單獨的方法中.
2. 如果某個函數上面的注釋在解釋這個函數是做什么用的, 多數情況下是這個方法名的名字取得不是很好, 通常使用 Rename Method 進行重命名.
3. 如果注釋在解釋代碼運行到這邊需要滿足的條件, 考慮使用 Introduce Assertion.
另外, 我覺得過分的追求代碼中沒有注釋也是不對的, 注釋需要恰到好處.
長的方法 (Long Method)
1. 尋找代碼中的注釋, 使用 Extract Method 將函數分成一小塊一小塊的方法.
2. 觀察代碼中有沒有太多重復的代碼, 使用 Extract Method 把這些代碼分離出去, 在原來的代碼中調用這些小方法.
長的類 (Long Class)
造成類的代碼過長的原因可能有以下兩點:
1. 隨著時間的推移, 類中在不停的增加新的功能. 可以使用 Extract Class, Extract Subclass, Extract Interface 解決這個問題.
2. 類中有很多涉及界面的代碼, 比如更新某個控件. 可以使用 Duplicate Observed Data 來幫助提取一個用于更新界面的類, 也就是所謂的 "界面與業務分離", 不過負責更新界面的這個類要寫好更新的同步機制.
長的參數列表 (Long Parameter List)
1. 如果參數能通過某個函數直接獲得, 應該去除該參數項, 使用 Replace Parameter with Method, 在函數中直接調用.
2. 如果某個物件能夠提供函數中所需的所有參數, 則可以將整個物件作為參數傳遞給函數, Preserve Whole Object.
3. 如果有好幾個函數都包含某幾個參數, 這幾個參數很有可能就是所謂的數據泥團 (Data Clumps), 如果合理, 嘗試使用 Introduce Parameter Object, 將數據泥團封裝到一個物件中, 讓函數直接調用這個物件.
重構, 各抒己見
一提到重構, 不少人有一肚子的口水要噴. 一部分人心懷激動的感概重構所帶來的諸多好處, 一少些人憤懣它所帶來的不屬于自己的利益, 甚至是某次不恰當的重構所帶來的毀滅性結果. 還有很多人在討論某項重構究竟值不值得去做 (這往往應該根據不同情況具體分析后做出不同的選擇).
對于重構, 就好比你想用積木搭一個建筑物, 重構就像是把一塊木頭削成一個個小積木的過程, 而如何去搭建, 大部分是設計模式所要解決的問題. 重構所能帶來的好處大多數的共識是: 重構后代碼能夠更讓別人讀懂和理解, 能發現代碼隱藏的缺陷, 幫助改善軟件設計, 新需求來臨時能提高編程效率。
記得我第一個獨立完成的程序是一個課程表軟件 (左圖), 用 VB.NET 寫的, 花了三天功夫寫了 2000 多行, 當時一共寫了近 10 個界面用于包括設置一個星期中每天的課程還有其它一些雜七雜八的內容. 當時我也知道 "重復" 的代碼很多, 但只想著 "能運行就好了", 于是還光明正大的把一大塊代碼復制到另外幾個模板里. 如果想對這樣的代碼做點優化的話, 這時不應該是重構, 而應該重寫. 后來我也不用這么笨拙的工具來存儲課程表了, 直接用 HTML+CSS 寫一個網頁.
不應該先亂七八糟的寫完一堆代碼之后再思考怎么去改善, 應該在寫得過程中不斷的嘗試著對現有的代碼作出一些優化, 最起碼別出現太讓人費解的變量名和方法名.
重構是一項需要不少時間的工作, 如果系統即將到了發布的 deadline, 這時并不適合大范圍的重構.
很多人覺得用不到重構, 他們覺得重構得不恰當會導致原本好歹能運行的系統工作不正常. 或者重構需要他們大把大把的精力和腦細胞, 而重構帶來的利益很可能不屬于他. 還有一些人不太喜歡頻繁的函數調用, 認為重構會降低一些系統性能等等原因. 但不要因為不會使用到重構, 而不去學習它, 更不用去抨擊重構帶來實際好處 (往往因為你沒體會到).
參考
這幾篇都是我看書并聯想自己寫過的代碼的總結, 廢話較少, 特別感謝不少細心的園友幫我糾正一些錯誤, 還提出了一些很有價值的建議.
參考 《重構 —— 改善既有代碼設計》, 《重構手冊》 , 還有自己的一些理解和經驗.
it知識庫:改善代碼設計 —— 總結篇(Summary),轉載需保留來源!
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。