何時開始重構?

“任何時候都可以重構”,如果這樣回答太過于寬泛,因為總有那么一些時候重構的 ROI (投入產出比)并不高,設置與對重構還不那么熟悉的開發者相當于什么都沒有說。

所以整理了下日常開發中進行重構的時間點,從而來幫助提升開發效率和重構效率。

02.png

如上圖:日常重構的時間點可以分為上述三個時間點。

  1. Tasking 之后,開發之前進行重構;

  2. 開發過程中,進行小步重構;

  3. 修復 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 類似,需要時刻保持重構的習慣。

總結

如果你對重構技藝已經非常精湛,并且能夠靈活控制重構對代碼添加、修改的影響,那么從各種場景來看“任何時候都可以重構”又是正確的,因為此時:能力決定了生產力

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。