“任何時候都可以重構”，如果這樣回答太過于寬泛，因為總有那么一些時候重構的 ROI （投入產出比）并不高，設置與對重構還不那么熟悉的開發者相當于什么都沒有說。
所以整理了下日常開發中進行重構的時間點，從而來幫助提升開發效率和重構效率。
如上圖：日常重構的時間點可以分為上述三個時間點。
Tasking 之后，開發之前進行重構；
開發過程中，進行小步重構；
修復 Bug 時進行重構；
01 Tasking 之后，開發之前進行重構
Tasking 指的是任務拆解（如果不熟悉，可以看這個視頻 或者 看這篇文章）,拆分過程中有可能會涉及到在原來的代碼上進行添加，因此可以在Tasking 過程中先了解原來的代碼，并將原代碼中發現的壞味道標注出來列在 Task 列表中。
因此在完成 Tasking 之后，其實就是一個時機來進行重構。當然有些重構并不是一開始做，而是隨著實現逐步引發小步重構。但是 Tasking 之后考慮何時重構絕對是一個事半功倍的時間點。
另外，在干凈整潔的代碼上添加新的代碼，也是更加容易的。
02 邊添加新代碼邊重構
Simple Design 在實現業務代碼時給我了我們很好的指導，能夠在實現代碼的過程中，保持代碼結構的簡單。除了技術上的重構也讓產出的代碼和業務貼近。
自上而下的開發方式，能夠幫助我們維護好代碼的層級結構。自上而下的開發方法過程中也需要 小步重構，來讓代碼在逐漸添加的時候，同時維持整潔。
重構時有個“事不過三，三則重構”的原則，指的是并不是每個 Smell 都需要一上來就聚焦消除，而是隨著重復障礙、重復代碼的出現次數增多而決定重構的輔助原則。其中的三次是個概數，指的是大于等于2次，至于第幾次進行重構，取決于你遇到的實際問題，可以延遲解決，也可以當機立斷立刻解決。
邊添加代碼邊重構，還能夠減少上下文切換的時間。當我們聚焦在一小段代碼時就可以重構，由于上下文邊界有小，很容易出現重構思路，并采用響應的手段。避免形成大段臟代碼之后才進行一次重構。在重構技巧上多加練習就能達到小步重構的能力。
03 修復 Bug 時重構
前面介紹的是添加代碼開始之前重構來讓后續工作更加高效，添加代碼過程中重構，保持開發效率的同時，時刻守護代碼設計。還有另外一種場景，就是修復 Bug。
修復 Bug 時，很容易由于修復而導致原本的設計收到破壞，如果原來的設計不合理那么我們當然應該修改它，如果原來的設計挺好，修改 Bug 的時候我們也應該進行重構，避免讓代碼因為后續的修改而逐漸腐敗。
另外一種場景時 Code Review 之后如果發現了某些壞味道或者設計缺陷，或者更好的實現方式，可以在 Code Review時利用 Todo 插件，編輯需要重構的點、需要重構的原因、重構的目標，并在當天將CR時發現的問題進行修復。這個修復Bug 類似，需要時刻保持重構的習慣。
總結
如果你對重構技藝已經非常精湛，并且能夠靈活控制重構對代碼添加、修改的影響，那么從各種場景來看“任何時候都可以重構”又是正確的，因為此時：能力決定了生產力
