[Day30] 淺談重構(refactoring)與兩把刷子
鐵人賽的最後一天,讓我們先來簡單的聊聊重構,這部分是筆者之前在看「大規模重構」這本書時整理的內容,目前只看了前幾章,所以能分享的還很有限,但到目前為止我很喜歡作者的觀點和態度。
重構的 what 和 why?
重構(refactoring)指的是「在不改變外部行為的情 況下,重組程式碼的過程」,也就是對於一般的使用者來說,重構前後的差異是不會被感覺出來的,而重構的目的是把原本隱晦、不易理解的程式邏輯、語法、撰寫風格等轉換成對其他開發者更容易上手和友善的程式碼。
先測試、再重構
有些時候或多或少都會有一種想要重構自己或他人程式碼的衝動,但要特別留意的是,在還沒有足夠的測試覆蓋率前,千萬不要貿然重構,因為有不小的機會,會改壞了某個功能而不自知,很多看起來莫名其妙的程式碼,常常有它的涵義在,可能是針對當下的某個 bug 採取的某種 work around,也可能是後來的開發者因為需求變更而隨手加上的邏輯,總之, 當你有一種「蛤,這在寫什麼」的感覺,有一種想要直接把它刪掉的衝動時,就更要小心! 不是不要重構它,而是要更小心謹慎的處理它。
可能的話千萬記得,先測試、再重構。
另外,重構時還有一種情境很常遇到,就是原本只想改重構某個範圍的程式碼,但改者改者卻發現這個功能到處都被使用、有彼此相依的情況,進而導致重構的範圍越來越大,又或是進入了某種重構的心流後,一發不可收拾,甚至開始包山包海。這幾種情況都要特別留意,因為很容易讓 Code Review 的人很難看懂,如果可以,請試著把重構範圍縮限在他人能夠審視的範圍(這句話其實是特別在跟我自己說的,對不起了同事,傷了你們的眼睛 🧎♂️)。