大家好，我是Z哥。
關于重構的文章之前也寫過兩篇：
《接手歷史悠久的老項目，干or跑？》
《好的重構方法才能擺脫“屎山”》
但是這兩篇主要講的是重構的方式方法。在 Z 哥看來，除了方式和方法還有一個點對于重構這件事來說也很重要，就是如何能夠實現“小步重構”。
因為只有“小步”地進行重構，才能達到那種未雨綢繆、防范于未然的效果，將風險扼殺在搖籃里。
所謂“善戰者無赫赫之功”，我是非常不提倡以“憋大招”的方式在某個時期重寫一個新系統的，不但風險大成本也大。
但是要實現“小步重構”，需要平時注意一些細節，下面我來分享一些我的經驗。
首先，歸根到底重構就是償還技術債。所以小步重構之前我們首先要有一種比較好的方式來對待技術債。
不知道你有沒有過這樣的經歷：
在編碼實現一個功能時，發現有一個邏輯如果按照全面去考慮的話需要改動很多地方，甚至可能要推翻當前已經寫過的部分代碼，但是呢現在實際場景并沒那么多，當前的實現已經能滿足。算了，先這樣吧，后續業務怎么發展還不知道呢，到時候再說。
這就是一種很常見的債務，并且這種債務很容易讓人忽視，因為它并沒有讓你在當下做出什么曲線救國的事情，只是一種“短視”的妥協。但是這種妥協一旦多了之后，后續的迭代往往會有很多大大小小的補丁來覆蓋之前沒有考慮的場景，最終積重難返，因為項目難以繼續維護而重寫。
上面提到的“大大小小的補丁”其實就是另一種常見的債務，這些補丁往往伴隨著 if-else 這種代碼出現。大家也都知道，if-else 代碼如果過多的話，對人的閱讀是非常不友好的。
技術債還有很多，我想每個程序員其實都能識別出來。對待它們的方式不同，最終形成不同人之間工作成果的差異。
Z哥推薦你對待技術債的方式很簡單。就是在代碼里增加 todo，然后將清理 todo 作為一個固定的任務安排，定期進行。
記 todo 看上去是一個簡單的事情，但是還是值得花點心思來提高效率的。常見的場景比如：
有一些改動需要涉及到多個地方，那么可以用某種標識（我習慣用當前時間精確到分鐘）來統一標注一下，這樣后續修改的時候就不會出現只改了一半導致出現 bug 的情況。
有些重構可能依賴于一些其它的改動才能進行，那么也可以把依賴的改動信息寫一下，如果所依賴的地方恰好也在本項目內，還可以備注一下相關的文件名和方法名。
有些重構還可能有一些 deadline 的約束，比如需要在 xx 日期前完成，那么也可以備注一下。
我平時用的 todo 格式是：
//todo：描述需要做什么重構。（202206121536）。依賴于xxx文件中的方法xxx。需要在2022.7.30前完成
做好了備注，剩下的就是定期清理 todo 了，這個需要根據當前的工作飽和度來安排，但 Z 哥建議，哪怕非常忙，至少 1 個月要進行一次。
好了，這篇呢 Z 哥和你分享了我對小步重構這件事的看法和經驗。
重構一定是小步快跑式的方式是最好的，不但可以降低風險，從長期來看所耗費的成本也是最低的。具體的做法也很簡單就是記 todo 和定時清理。
關于重構的一些方式方法可以查看我之前寫的兩篇文章。
《接手歷史悠久的老項目，干or跑？》
《好的重構方法才能擺脫“屎山”》
希望對你有所幫助。
對了，最后還有一個建議強烈推薦給你。就是沒有調用的方法盡早刪除，不要留著覺得以后可能還會用。根據我這么多年的經驗來看，未來再會用到的概率微乎其微，留著反而增加了后續的代碼重構成本。因為當你修改一個方法或者字段，然后通過IDE查找引用的時候，這些其實已經沒有調用的方法也會被關聯到。
推薦閱讀：
原創不易，如果你覺得這篇文章還不錯，就「點贊」或者「在看」一下吧，鼓勵我的創作 ：）
也可以分享我的公眾號名片給有需要的朋友們。
如果你有關于軟件架構、分布式系統、產品、運營的困惑
可以試試點擊「閱讀原文」
 功能，輕松限制請求數量)
)
)
