# CH2 重構的原理 ---- 理論的部分 - What - How - Why - When & When not - Others --- ## 何謂重構 (What) ---- ### 重構 (動)(名) 以不改變**可見行為**的前提 - 提高可理解性 - 降低修改成本 ---- ### 可見行為 - 可能改變：程式執行的性能、介面模組 - 不會改變：程式的功能面 ---- ### 每一個重構本身都非常小型 > 進行重構時，程式碼不會長時間處於無法運作的狀態 > ---- #### 代表重構隨時可以停下 - 開發時間不夠，在`重構`跟`功能開發`中做出平衡 - 有緊急的 task 要處理，當下的進度也可以提交 --- ## 兩頂帽子 (How) - 功能開發 - 重構 - 重構時發現的 bug 依然存在 > :coffee: commit = 替換帽子？ ----  --- ## 為何重構 (Why) > 重構是**經濟效益**的考量 ---- ### 改善軟體設計 - 軟體久了就會劣化 - 過多重複的程式碼 > 醜陋的程式碼必須重構，但是優秀的程式碼也需要大量的重構 ---- ### 增加可讀性 幫幫未來的開發者（包括自己） > 讓我希望它做的事情 = 我告訴它做的事情 --- ## 何時該進行重構（When） ---- ### 三次法則 > 被三振，就重構 ---- ### 幾個時機點（見機行事） - 預備性 - 加入新功能前 - 防止劣化、過多重複的 code - 理解性重構 - 可讀性 - 藉由重構將理解寫到程式碼本身，讓理解保存存更久 - 打掃性 - 可以取捨的 ---- ### 幾個時機點（規劃） - 計畫 & 長期重構 - 拆成小步驟 - 重構不會破壞程式碼 ---- #### 該如何向主管報告？ > :coffee: 站在專業人士的角度上，不要對主管或顧客說出來？ --- ## 何時不該重構（When not） 如果不需要修改它，就不要重構它 > 重構是**經濟效益**的考量（Why） --- ## 重構的難題 > 長久的重構過程就像投資 ---- ### 重構減緩開發速度？ - 龜兔賽跑 ---- ### 持續整合（CI） - 避免跟主線分離太久 - 需要 **厚實的功力** - 事先規劃 - 大功能要拆小 - 功能開關（flag） ---- ### 測試！！！ - 確保功能性沒有破壞 - 需要自檢（self-testing）的程式碼 - Unit test ----  ---- :coffee: > 測試覆蓋率？ > 大多沒有測試怎麼辦？ --- ## 其他關於重構（Optional） ---- ### 重構、架構與 Yagni - 重構是 Yagni 的基礎 - 過度彈性反而降低對變化的反應能力 - 先想一下將來再用重構來修改會不會很難 - 更瞭解問題時再處理 ---- ### 重構與性能 - 可讀性優先 - 真的遇到性能問題再處理 ---