我是一個著迷于產(chǎn)品和運營的技術(shù)人，樂于跨界的終身學習者。歡迎關(guān)注我喲～

每周五12點 按時送達～

我的第「227」篇原創(chuàng)敬上

大家好，我是Z哥。

(資料圖片)

關(guān)于重構(gòu)的文章之前也寫過兩篇：

但是這兩篇主要講的是重構(gòu)的方式方法。在 Z 哥看來，除了方式和方法還有一個點對于重構(gòu)這件事來說也很重要，就是如何能夠?qū)崿F(xiàn)“小步重構(gòu)”。

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

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

但是要實現(xiàn)“小步重構(gòu)”，需要平時注意一些細節(jié)，下面我來分享一些我的經(jīng)驗。

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

不知道你有沒有過這樣的經(jīng)歷：

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

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

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

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

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

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

我平時用的 todo 格式是：

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

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

好了，這篇呢 Z 哥和你分享了我對小步重構(gòu)這件事的看法和經(jīng)驗。

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

關(guān)于重構(gòu)的一些方式方法可以查看我之前寫的兩篇文章。

希望對你有所幫助。

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

推薦閱讀：

也可以「關(guān)注」我，帶你以技術(shù)思維看世界～

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

內(nèi)容包括：架構(gòu)設(shè)計丨分布式系統(tǒng)丨產(chǎn)品丨運營丨個人深度思考。

責任編輯：Rex_08