重構:你可能不知道的重構場景

了不起的廠長發表於2019-05-13

什麼是重構?

“重構”一詞想必你已經聽膩了,就是整理程式碼唄,不不不,重構旨在不改變呼叫者行為的前提下,對內部邏輯進行調整優化,提高其理解性,降低其修改成本,它是一門藝術,是程式設計師至高無上的榮耀……

何時重構?怎麼重構?

經常聽到周邊的人抱怨沒有時間重構,重構並不是單獨抽出時間集中處理的,而是當你想要做某個功能時,隨手把需要重構的地方安排了。

邏輯重複

重複程式碼是最核心常見的預警資訊,如果有兩個及以上的重複邏輯,就應該考慮將其合併。比如同一類或不同類中的函式存在相同邏輯的部分,就應該把相同部分抽象為獨立函式或類。

長函式

應該有很多同學經手過別人數百行甚至上千行的程式碼,讓人質疑人生。為方便理解,最好的方式是把長函式分解為若干小函式,搭配上易理解的函式名,便可以像自然語言一樣理解程式碼。

引數過多

有一種習慣非常不好,就是把所有要用到的變數當做函式的引數,這樣會加劇程式碼的理解難度,擴充極其困難,當需要更多資料時,不得不修改所有函式的引數,牽一髮動全身。如果把物件作為引數,需要用到的資料都放進物件裡,就可以有效解決引數過長的問題。

函式出軌

你要是發現一個函式頻繁的呼叫某一個類,它很可能給你戴了綠帽子,不如忍痛割愛,放其自由吧,把函式歸併到它喜歡的類,也許他們在一起生活更為合適,你一定會找到一個適合的人。

變化擴散

如果新加入一個業務型別(例如支付渠道、資料庫型別等)時,需要改動很多地方才能實現,這就意味著還有改進的空間,可以將引起變化的原因抽出來做為配置,並將變化的函式放置到一個類中,這樣不僅可以做到修改一處就應對變化,還可以很清晰的知道哪些函式會受到影響。

工具小助手

一款語言包含很多基本型別與內建函式,但不能滿足所有需求,比如金額單位轉換、時間陣列格式轉換、UUID生成等簡單又容易忽略的小功能,如果這些功能出現的頻率很高,規則改變會帶來一連串的修改,這時可以考慮將這些小功能抽象為工具函式,並將這些函式組合為工具類。

意淫的功能

有些邏輯以為將來會有一些變化,於是安插了很多鉤子函式應對非必要的特殊情況,這樣往往提高了系統複雜性和理解成本,如果安插的鉤子都能被用到且有價值,那麼就使用,否則還是不要放在程式碼裡阻礙視線了。

switch過多

假如現在要做一個支援微信、支付寶、招行等渠道的支付平臺,需要對接不同渠道,因為不同渠道對接方式不同,就需要用switch來根據型別選擇對應渠道的對接方式,但是很多地方都可能用到這個switch,一旦新渠道加入就要滿世界的找哪裡用到了switch。

可以將switch語句移植為獨立的函式,將這些函式組成基類,case語句呼叫子類對應的函式,具體實現讓子類去完成,這樣支付渠道的增加和變更只需要修改一個類即可。

多餘的類

建立的每一個類,對於其他人來講都是有理解成本的,如果曾經為某個變化所新增的類,在實際場景中並沒有發生變化,那麼就把這個類去掉吧,我們需要真正有價值、理解成本低的系統。

讓人犯暈的變數

一個類會設定一些為特殊情況設定的變數,這些變數不一定都會被使用,經手你程式碼的人還要猜測當時設定這些變數的目的,非常讓人頭大,不如把這些變數和相關函式單獨放在一個類中,遮蔽具體細節,需要的功能通過函式來表達,會使功能擴充套件更高效。

幽靈類

專案中偶爾會出現一些“幽靈類”,這些類沒有做什麼實際工作,只是負責呼叫其它的類,不如把這個“中間人”去掉,讓實際要呼叫的那個類與呼叫者發生關係。

雷同的類

如果兩個類,其中某幾個函式作用相同,名稱不同,那就可以通過修改名稱或移植函式的方式將兩個相似的類保持一致,然後把兩個類抽象出基類,以便擴充套件。

過多的註釋

註釋多並不是一件壞事,它是重構的領路人,當你感覺需要為某段程式碼寫上註釋時,這意味著你認為這段程式碼不容易被他人理解,也側面證明了這就是重構發出的預警訊號,所以當想要寫註釋時,就先重構,爭取讓註釋都變得多餘。

相關文章