更新於 2024/12/01閱讀時間約 5 分鐘

【重構-改善既有程式的設計】讀後感

《重構》第二版
《重構》第二版

引言

Any fool can write code that a computer can understand. Good Programmers write code that humans can understand.                     — M. Fowler (1999) 任何一個傻瓜都能寫出電腦可以理解的程式,唯有優秀的程式設計師能寫出讓人讀懂的程式。

上述引言是個人在讀完本書後蠻喜歡的一句話。初學程式時認為寫程式是在跟機器溝通,它懂了、可以動了,我的目的達成了,結案!然而大多時候,光是連編譯器吐出來的錯誤訊息都看不懂,更別說是考慮自己寫出來的程式碼的可讀性,而且專案太小也感覺不出維護上的困難。
工作後見識到老舊專案的核心程式,疊床架屋的結果下加新功能,每一步都得小心翼翼。理解既有程式碼要花時間,更改程式碼也是一項大工程,尤其是在多人協作開發的環境下,程式碼的品質更顯重要。
接續之前的clean code演講,偶然在書店看到了演講中提到的《重構》第二版。作者為了讓更多人容易吸收書中想表達的意涵,第二版範例改用javascript呈現。老實說讀技術相關的工具書,中文翻譯常常會混淆一些名詞所表達的意思。不過比照大學啃原文書的方式,看懂了範例就成功了一大半,順便培養作為工程師必備的基本能力--推敲上下文(通靈)。

定義何謂重構

重構指在不改變程式原有行為的基礎上,對既有程式碼進行修改,以改進其內部結構。
簡單從定義上,站在管理者的角度來說,佔用了時間卻沒有任何產出!況且高機率會遇到以下情況:
  1. 原本正常運作,為什麼要改?
  2. 都是你把它改壞的!
  • 第1種狀況:最好的情形下,要有能說服長官的依據,只是過多不可控因素考量,不如不要讓長官知道你在重構!
  • 第2種狀況:必須要確保能夠安全的重構,具體的方式即:先撰寫測試。

撰寫測試

這裡帶到了測試驅動開發的概念(Test-Driven Development, TDD),在完成產品的程式碼前,應該要建立對應的測試程式碼,並且每一次的改動都要能通過原有的測試案例。一方面,這些測試案例也透露出開發程式碼應達到哪些基本的功能要求,讓需求意圖跟著被保留下來。另一方面,在重構的過程中,開發人員也會間接被要求寫出更容易被測試的程式碼,讓程式單元趨向單一職責(Single-responsibility principle, SRP )。

善用整合開發環境(IDE)

Java常用的IDE(IntelliJ, Eclipse)或是微軟Visual Studio內插件支援resharper,都可以幫助開發者進行重構,包含擷取方法、擷取類別、變數內嵌或是重新命名。
以我自己遇到的專案為例,從前輩手中接手上千行的批次程式,在沒有撰寫測試程式碼的狀況下,只能不斷擷取出方法,並且個別給予能描述其方法的命名,順便梳理整個大區段程式碼的邏輯。如此一來,就算執行後還是出現問題,也能快出推斷出是哪一個單元發生狀況,最後順利在上線前,額外多解決了幾個bug。
// 修改前示意
function main() {
  ...
  ...
  ...
}

// 修改後示意
function main() {
  doOneThing();
  doAnother();
  doTheOther();
}

function doOneThing() {
  ...
}

function doAnother() {
  ...
}

function doTheOther() {
  ...
}

結尾

The whole purpose of refactoring is to make us program faster, producing more value with less effort.
書中後面章節大多是重構時所使用的手法,因此了解前面幾個章節作者所要表達的概念及範例後,在開發上也會有更新一層的認知。
整體而言,更適切的達到實質的clean code。
  • 無暇的程式碼
  • 清理程式碼
分享至
成為作者繼續創作的動力吧!
© 2024 vocus All rights reserved.