Retrospective

為什麼要多這個練習

寫程式是需要「在意成本」這件事情的，尤其在精實原則中有一項最重要的價值：盡量延遲決策(Decide As Late As Possible)，以寫程式來說，如果有無限時間、無限權限工程師八成會直接把程式重寫（誰還管refactoring呢？重寫不就得了），但是現實上會有成本的問題， 所以說，想要學好Refactoring，學會評估修改範圍以及修改所需的成本是非常重要的（專案時間內如果要大規模refactoring情況下是需要制定良好策略的）！

Take a look at （範例連結）

TennisGame1的壞味道

• Mysterious Name

     說明：m_score1、m_score2這樣來說命名不夠精確，會改以命名player1Score、player2Score的方式命名

 

• Repeated Switches

     說明：getScore()中有兩處switch，都與分數的表現有關，大致上雷同的

 

• Mutable Data(我認為是這個範例最重要的code smell，你認為呢？)

     說明：變數score是顯示分數訊息的變數，當它足以呈現它的顯示資料時就應該return才對，變數異動範圍越小越好。（這裡的檢測我是這麼做的 將if(){....} else if(){.....} else{}中的”else“移除後做測試，發現有”紅燈“）

 

• Temporary Field

      說明：變數tempScore，我想這是很明確的壞味道

 

心得

當初練習第一種版本的時候， 心裡會覺得說我真的是重構嗎？還是我在重寫？因為這個範例太熟悉了，導致其實很大部份我認為我應該是在重寫，會寫出這篇是因為想更增進判別「壞味道」還有「重構策略」的應用，盡量去使用ide的自動化功能，盡力用更柔和的手法重構

這版改進策略是這樣的：

我從很簡單的rename開始，將命名奇怪的變數刪掉；然後我做了Mutable Data說明中談到的if結構檢測，我認為應該score處理好之後就立刻return掉以免污染，所以處理好的部分我選擇加上return，測試過後確實可以如此處理（有測試保護真棒！），下一步就可以處理switch重複的部分。

處理switch的部分是要勇敢處理deuce condition邏輯與增加switch 的結構，有測試保護的時候就勇敢的上吧！但是但是，此時的你完全選擇簡單的清理if 與extract class就停在這裡就好，因為比較重點的Code smell都處理掉了（Mutable Data、Repeated Switches)，參考：https://github.com/ryanGTR/Tennis-Refactor-kata/tree/refactor_tennisgame1_1_another

重構可以視決策範圍決定的(你可以看看重構-改善既有程式碼的2.4章節 何時重構，裡面有談到撿垃圾式重構)，因為重構的妙處就是每個小步驟都不會破壞程式。

當然有餘力就重構到底囉！！！

詳細步驟連結：https://github.com/ryanGTR/Tennis-Refactor-kata/tree/refactor_tennisgame1_1