Refactoring: Impoving The Design of Existing Code

中譯：重構-改善既有程式的設計

前言

古老的工程諺語：「如果它還能執行，就不要動它」
 但專案功能不斷修改程碼，使原先系統結構逐漸衺弱，程式碼也更加複雜，無法除錯，也無法獲得可被接受的性能/效率
最後重新編寫整個系統，作者指出堅持以持續不斷的重構行為是成功專案的重要角色

重構：「在不改變程式碼外在行為的前提下，對程式碼做出修改，以改進程式的內部結構」

軟體會慢慢腐爛
 重構的步驟只要把某欄位(field)從一個class移到另一個class,把某段程式碼從method拉出成另一個method,或是在class hierarchy中把某些程式碼推上推下就行了，聚沙成塔，小小的修改累積就可以改善設計品質，這和「軟體會慢慢腐爛」的觀點恰恰相反

Ch1 Refactoring, a First Example

分解並重組method
案例中的錄影帶出租statement()做太多事，程式碼太長，可以其目的拆成至不同的class
每個method的程式碼越少越容易維護，且拆成 更多的method更容易reuse(copy-paste相同的程式碼，常發生改了a method忘了改相同容內的b method)

重構技術係以微小的步伐修改程式。改錯時，很容易發現它

更改變數是值得的行為嗎？(p.15)
好的程式碼應清楚表達自己的功能，變數名稱是程式碼清晰的關鍵

任何一個傻瓜都能寫出計算機可以理解的程式碼。唯有寫出人類容易理解的程式碼，才是優秀的程式員

Replace Temp with Query(p.21)
int thisAmount => each.getCharge()
儘量除去暫時變數，暫時變數會導致大量參數被傳來傳去。也很容易失去蹤跡=>相對要付出效率上的代價，但可由最佳化來調整(細節p.69)

運用多型取代與價格相關的條件邏輯(p.34)
=>引用State pattern
在父類別宣告abstract int getPriceCode(),讓子類別實作其條件，使其有自己的計費法
*另外邏輯判斷也該在物件本身的class(指switch(getMovie().getPriceCode())=>應在class movie裡寫switch (getPriceCode())
當有傳入值有可能有變化時，選擇可能變化小的，折起的side effect也較小
=>引用State pattern的重點在「修改與價格有關的行為」，或「新增定價標準」會較容易

Ch2 Principles in Refactoring

為何重構
-改進軟體設計=>消除duplicate code
-使軟體更易被理解
-助找到bugs=>程式碼易於理解，而不是從一個500行的method找

何時重構 The Rule of Three (p.58)
1.反感，第三次又做類似的事就該重構
2.添加功能時
3.修補錯誤時
4.code review時

Ch3 Bad smells in Code

何時重構、何時停止及重構的機制
1.Duplicated Code p.76
2.Long Method p.76
3.Large Class p.78
class太大，instance變數就會多，Duplicated Code也接腫而至
4.Long Parameter List p.78
5.Divergent Change(發散式變化) p.79
隨外界變化而有所修改，找出原因運幅Extract Clss提煉到另一個class
6.Shotgun Surgery(霰彈式修改) p.80
每遇修改就得在不同的classes內做小修改
7.Feature Envy(依戀情結)
某method內呼叫該class幾乎半打的getting method
8.Data Clumps
每次都會同時出現的幾個field
9.Primitive Obsession
日期年月日，3個int不如定義成object
原則
應放在一起的fields =>Extract Class
參數列中有基本型資料=>Introduce Parameter Object
從array挑資料 =>Replace Array with Object
10.Switch Statements