原文同步刊載於:
這篇文章會淺談什麼是重構(Refactoring)、為什麼做、何時做與如何做重構。
什麼是重構?
什麼是重構?就是改Code重寫?當然不僅僅是這樣。看看Martin Flowler的定義:
“A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior”
Martin Fowler
大概是說:改變軟體內部結構,使它簡潔易懂、有組織易修改,但不改變其行為
其中這裡講到一個關鍵就是:without changing its observable behavior
如果你同時增加新Feature又做重構,那你應該把這兩件事分開來做,先做重構,不改變原程式行為,然後再增加新Feature。
為什麼要重構?
重構(Refactoring)的主要目標就是要消滅技術債(Technical Debt),把混亂阿雜的程式碼改寫為潔淨無瑕的Clean Code,結構設計上化繁為簡,增加程式碼的可讀性,減少之後修改出錯的機率,但很重要的是,重構並不會改變原來程式的功能行為。
如果沒做重構,長久下來會發生下列問題:
- 生產力下降:
- 重覆的Code不斷增加
- 邏輯變的越來越複雜
- 程式碼變的越來越難理解
為什麼會產生技術債(Technical Debt)?
技術債的產生可能來自於下列原因:
- 能力不足:沒有太多寫程式的經驗去寫出一手好Code
- 意願不足:就是懶,不想花時間,便宜行事
- 資源(時間)不足:時程太趕,怕拖到上線進度,只想速速寫完交差
為什麼要消除技術債?
沒有技術債的程式,在做Code Change時會更容易也更迅速,消除技術債就是為了之後維護程式或開發新功能時能夠更輕鬆。
什麼時候要做重構?
答案是:持續進行,看到不好的就想辦法改,融入平時的工作中。
Boy Scout Rule:Leave your campground code better than you found it.
就像在露營,你的營地要乾淨,就不要亂丟垃圾,看到垃圾就撿起來,隨時維護營地的整潔。
在Refactoring Guru中提到下面這些情況就是做Refactoring的時候:
- Rule of Three:同一件事做3次,就該開始refactoring
- When adding a feature:別人重構可以幫助你了解他們的code,當你新增feature時,你也要試著寫出Clean Code,或重構別人的相關的Dirty Code
- When fixing a bug:有bug的code就是最髒的code,把code整理乾淨基本上就很容易發現bug
- During a code review:在Code被merge到專案前,是個機會好好的看看code寫的好不好,要求整理乾淨
什麼時候不要做重構?
什麼時候不需要去做消除技術債的動作?
- 現在的code根本不work,壞掉的code
- Deadlines必需met,正事先做完,不能拖到進度
- 程式已經夠好了,就不需要Refactoring
Business is well served by continuous refactoring, yet the practice of refactoring must coexist harmoniously with business priorities.
Joshua Kerievsky
如果你說你為了要讓程式碼變好看一點,所以拖到了上線進度,那是不行的
如何進行重構?
首先,你必須確保你的重構不會搞壞東西,也就是說如果重構前,測試都是Pass的,但重構後,雖然code變整齊但測試Failed,這樣是不行的。
Refactoring的流程如下:
- 再重構之前,先驗證目前的程式行為是正確的
- 跑測試,確保目前的測試都通過
- 重構
- 再次驗證測試都通過,行為也正確
之後的章節會再針對第3步重構的部分做細節的說明。