引言

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. 都是你把它改壞的！

• 第１種狀況：最好的情形下，要有能說服長官的依據，只是過多不可控因素考量，不如不要讓長官知道你在重構！
• 第２種狀況：必須要確保能夠安全的重構，具體的方式即：先撰寫測試。

撰寫測試

這裡帶到了測試驅動開發的概念（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。

• 無暇的程式碼
• 清理程式碼