Refactoring 2nd 閱讀心得
CH1 與 CH2 讀後感
前言
整潔的程式碼簡單直接。整潔的程式碼如同優美的散文。整潔的程式碼從不隱藏設計者的意圖，充滿了乾淨利落的抽象和直截了當的控制語句。 — Robert C.Martin
Repo 位置與 Commit 記錄
為了讓使用者閱讀方便，以及忠實呈現重構過程，每個修改都有其對應的 commit 記錄，我直接在 commit 內容中加入書中使用的重構技巧，這樣可以做的好處有
- 每個 commit 顯示程式碼逐步完善的過程記錄
- 每個小修改讓讀者邊讀邊對照，從程式碼異動紀錄中感覺到整體，而不是透過書中部分程式碼重現
- 每個 commit 記錄中，使用的重構技法加上本書頁碼，方便讀者反覆來回對照
https://github.com/mybaseball52/refactoring-2ndCH1 閱讀後的感覺
首先，很開心《重構》出了第二版的書，而這次的書採用的是 JavaScript 語言，我記得在看第一版的書的時候，使用的是 Java，但是因為 Java 寫太少，所以讀起來沒什麼感覺，可是透過這次的版本，我在閱讀的過程中，我確確實實感受到重構的威力，並且有種見樹又見林的感覺。
而在 Fowler 所提倡的重構方法，除了我們要記一些重要的名詞重構法之外，最讓我感到印象深刻的地方便是：
- 作者透過簡單的例子帶領讀者了解重構程式碼的情況
- 我們在重構程式碼經歷了：閱讀、思考產生見解、透過重構原則使程式碼品質更好，把見解寫進程式碼中
- 決定程式好壞的關鍵在於它有多容易被修改
- 重構小步驟而節奏快，是最有效的
CH2 閱讀後的感覺
為什麼程式設計師要一直不斷重構他所寫的程式碼？網路上打「程式碼重構」幾個字會跳出不少的資料。但是為甚麼是重新構造程式碼，而非直接重寫已經出問題的程式碼了？
在軟體開發過程中往往開發者不經意間就能產生程式碼的壞味道，特別是團隊人員水平參差不齊每個人的經驗和技術能力不同的情況下更容易產生不同階段的程式碼壞味道。並且隨著需求的迭代和時間推移，程式碼的壞味道越來越嚴重，甚至影響到團隊的開發效率，那麼遇到這個問題該如何去解決。
透過重構，主要是希望要掌握以下要點：
- 增加程式可設計性
- 增加程式可讀性
- 將程式的缺失暴露出來
- 幫助你的程式可以運作更快
另外，書中(包括我自己的經驗)也針對什麼時候該重構什麼時候不該重構作出以下看法：
- 實踐 TDD 時
- 對於更改程式碼感到不方便時，就進行重構
- 為了便於新增功能
- 修 Bug 時，順便針對修改的部分做重構，使之更堅固
- Code Review 時
那什麼時候不該重構？
- 當遺留的技術債太大時，不適合下重本進行重構
- 現在的程式碼無法運作 => TDD 也是綠燈時才重構
- 專案快死線時
結論
綜上所述，我整理了以下的筆記：
重構程式碼原則
- 保持簡單原則
- 保持程式碼符合 DRY 跟 YAGNI 原則
- 使程式碼閱讀起來更直觀易理解
- 盡量減少整體的程式碼
- 分離關注點(SRP 原則)
- 適當地進行抽象化(不要老是遇到相似邏輯就使用 Push Up Method)
重構的流程：
首先，你要 Check in 或備份要修改的現有程式碼，接著確認欲重構的程式碼是可執行的(記得， CH2 開頭說明重構不是讓程式碼不能動，而是在每次修改都能執行下做重構)，而且是執行產生的結果是符合產品驗收準則的。
接著，我們在重構之前，如果程式碼沒有單元測試，先加入 characterization test，就可以進行重構了，最後，就是確認重構後的結果是跟重構前執行的結果一模一樣。
幾個簡單的小訣竅：
- 保持小塊地進行重構
- 一次做到位
- 常常 Check in 程式碼
- 可以的話，最好增加 Test Case 來自動化部分的邏輯驗證
- 檢視成果
注意不要過早最佳化程式碼，例如把只分別出現在不同的 class 的兩個類似的邏輯做 Push Up Method。
