我是一個著迷于產品和運營的技術人，樂于跨界的終身學習者。歡迎關注我喲～

每周五12點 按時送達～

我的第「227」篇原創敬上

大家好，我是Z哥。

(資料圖片)

關于重構的文章之前也寫過兩篇：

但是這兩篇主要講的是重構的方式方法。在 Z 哥看來，除了方式和方法還有一個點對于重構這件事來說也很重要，就是如何能夠實現“小步重構”。

因為只有“小步”地進行重構，才能達到那種未雨綢繆、防范于未然的效果，將風險扼殺在搖籃里。

所謂“善戰者無赫赫之功”，我是非常不提倡以“憋大招”的方式在某個時期重寫一個新系統的，不但風險大成本也大。

但是要實現“小步重構”，需要平時注意一些細節，下面我來分享一些我的經驗。

首先，歸根到底重構就是償還技術債。所以小步重構之前我們首先要有一種比較好的方式來對待技術債。

不知道你有沒有過這樣的經歷：

在編碼實現一個功能時，發現有一個邏輯如果按照全面去考慮的話需要改動很多地方，甚至可能要推翻當前已經寫過的部分代碼，但是呢現在實際場景并沒那么多，當前的實現已經能滿足。算了，先這樣吧，后續業務怎么發展還不知道呢，到時候再說。

這就是一種很常見的債務，并且這種債務很容易讓人忽視，因為它并沒有讓你在當下做出什么曲線救國的事情，只是一種“短視”的妥協。但是這種妥協一旦多了之后，后續的迭代往往會有很多大大小小的補丁來覆蓋之前沒有考慮的場景，最終積重難返，因為項目難以繼續維護而重寫。

上面提到的“大大小小的補丁”其實就是另一種常見的債務，這些補丁往往伴隨著 if-else 這種代碼出現。大家也都知道，if-else 代碼如果過多的話，對人的閱讀是非常不友好的。

技術債還有很多，我想每個程序員其實都能識別出來。對待它們的方式不同，最終形成不同人之間工作成果的差異。

Z哥推薦你對待技術債的方式很簡單。就是在代碼里增加 todo，然后將清理 todo 作為一個固定的任務安排，定期進行。

記 todo 看上去是一個簡單的事情，但是還是值得花點心思來提高效率的。常見的場景比如：

我平時用的 todo 格式是：

//todo：描述需要做什么重構。（202206121536）。依賴于xxx文件中的方法xxx。需要在2022.7.30前完成

做好了備注，剩下的就是定期清理 todo 了，這個需要根據當前的工作飽和度來安排，但 Z 哥建議，哪怕非常忙，至少 1 個月要進行一次。

好了，這篇呢 Z 哥和你分享了我對小步重構這件事的看法和經驗。

重構一定是小步快跑式的方式是最好的，不但可以降低風險，從長期來看所耗費的成本也是最低的。具體的做法也很簡單就是記 todo 和定時清理。

關于重構的一些方式方法可以查看我之前寫的兩篇文章。

希望對你有所幫助。

對了，最后還有一個建議強烈推薦給你。就是沒有調用的方法盡早刪除，不要留著覺得以后可能還會用。根據我這么多年的經驗來看，未來再會用到的概率微乎其微，留著反而增加了后續的代碼重構成本。因為當你修改一個方法或者字段，然后通過IDE查找引用的時候，這些其實已經沒有調用的方法也會被關聯到。

推薦閱讀：

也可以「關注」我，帶你以技術思維看世界～

想更進一步和我一起玩耍，歡迎「搜索微信公號：跨界架構師」。

內容包括：架構設計丨分布式系統丨產品丨運營丨個人深度思考。

責任編輯：Rex_08