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