Part.1

為什么程序員一言不合就重構代碼？

?

? ? ? ?當你看到前任寫成一團毛球的代碼塊；新增幾行代碼需先捋半天邏輯的超級大函數(shù)；好不容易在迷宮里找到方向，小心翼翼地添加上新代碼，卻將別的調(diào)用系統(tǒng)給弄垮時；還有運行緩慢的老系統(tǒng)……

? ? ? ?此時程序員只有兩個選擇：要么忍，要么重構。

? ? ? ?忍是有極限的，重構的“三次法則”表示：程序員第一次看到亂代碼可以繞過去，先將手上的代碼堆好；第二次再碰上這塊，心里雖反感但再一次勉強繞過；第三次肯定忍不住動手。

以下的場景是不是很熟悉：

測試：這么小的功能，你為什么改動300多個文件？

開發(fā)：嘿嘿嘿，我順便將老代碼挪了地方。

測試：你知道這給我增加多少測試工作量嗎？那些我都得回歸一遍。

開發(fā)：不用測試，沒有風險的，我就整理下代碼。

測試：你上次也這么說，結果偷偷改了某接口，影響到下游系統(tǒng)。還有那次啊你……

產(chǎn)品：你又在弄重構？我這還有一大堆需求沒人開發(fā)。

開發(fā)：我這的重構系統(tǒng)也非常重要的。

產(chǎn)品：哪里重要了？你浪費這么多人力重構，用戶也看不出來系統(tǒng)有什么變化，搞不好還弄壞老功能。求求你別重構了。

開發(fā)：我……

? ? ? ?雖然重構不被其他角色認可，但你的程序員同事會理解和感謝你的，重構是優(yōu)化代碼設計，使代碼可讀性更強。

? ? ? ?只是重構是個大坑，不小心就掉坑里。

Part.2

“等重構完這個系統(tǒng)，我就提離職。”龍哥說。

?

? ? ? ?由于核心系統(tǒng)初期設計不當，權責界限模糊，只要沾點邊的代碼都往上堆，造成系統(tǒng)過于龐大，邏輯混亂，一出現(xiàn)問題，造成核心業(yè)務癱瘓。

? ? ? ?過老過大過中心的系統(tǒng)像個不定時炸彈，吃過幾次虧后，業(yè)務組決定拔掉這隱患：將系統(tǒng)重構，按照業(yè)務處理邏輯拆分成各功能單一的子系統(tǒng)，降低耦合度。

? ? ? ?大伙把這事當作季度最重要的計劃來開展：熱火朝天的開會劃分系統(tǒng)，梳理代碼邏輯，安排測試，聲明注意事項。

各人領了任務后，開始埋頭苦干起來。

? ? ? ?但是重構系統(tǒng)像從一個大迷宮捋線路，捋的過程耗費巨大，而且極易遺漏。產(chǎn)品后來提的新需求直接在重構后的系統(tǒng)里新增。開發(fā)團隊進入惡性循環(huán)：新增功能有的人在老系統(tǒng)分支改，有人在新的改，導致提交的代碼分支混亂，搭建過程緩慢，計劃的任務delay，最后測試人員發(fā)現(xiàn)很多遺漏點，又返工重構。

? ? ? ?大家不斷埋頭地捋代碼，重構，測試，想百分百完美地完成任務，而忽略整體項目進度的把控。

? ? ? ?上線時間從9月份推遲到12月份，再到年后，最終來年6月份系統(tǒng)才上線完成，耗時一年多。

? ? ? ?每個人被重構折磨得疲憊不已，還短時間看不出來效果，可已經(jīng)投入人力物力，大家只好硬著頭皮往下走。后來大家已經(jīng)想不起當初為什么要重構，到底要重構到什么樣子，只想著這重構何時到頭，什么時候才能解放。從重構半年時開始有人離職，到上線時僅剩一個原項目組的產(chǎn)品，他說這項目終于結束，我也該走了。

Part.3

? ? ? ?上面的重構沒有合理的項目規(guī)劃，還犯了重構的大忌：邊重構代碼邊新增功能，這樣相當于將原系統(tǒng)推翻重做，風險極大。

那么該如何合理的安排重構呢？

?

1.遵循“兩頂帽子”重構原則

? ? ? ?在重構時，兩個不同的操作分開進行：重構代碼和新增功能。

先在不改變原系統(tǒng)功能的基礎上修改現(xiàn)有代碼的設計，這樣采用原有的測試方法可以輕松地驗證這些修改的正確性。

再在已重構好的基礎上增加新功能，使得新功能與老功能合理解耦。

上述例子里，業(yè)務組邊重構邊在上面新開發(fā)功能，給測試人員的壓力巨大，原有的測試方法全不適用，增加回歸測試工作量。

2.使用“小步快跑”的重構策略

? ? ? ?重構避免使用“大布局”規(guī)劃項目進程，如果從整理需求、設計接口、開發(fā)聯(lián)調(diào)、測試上線，經(jīng)歷幾個月的時間，如果其間有問題，整個團隊又得人仰馬翻地去調(diào)整方向，試錯成本過高。“小布快跑”是讓我們重構時只關注一個問題點，只解決這一個問題。小改動，小局部優(yōu)化，耗時短，見效快。

這便需要我們將重構當作一個習慣，融入在每一次代碼修改中。

3.測試驅動開發(fā)

? ? ? ?上文例子里將代碼的質量保證全丟給測試人員，光是對整個系統(tǒng)接口的性能測試就耗費大半個月的時間，等測試人員將問題列表整理后又得重新改代碼，不單浪費時間，還可能引入大風險。

? ? ? ?正確的重構姿勢是將測試融入在每一次重構中，小步快跑，修改一塊代碼便自測這塊，等調(diào)通后再繼續(xù)往下走。重構有風險，開發(fā)測試兩手捉。

? ? ? ?《重構》一書里說道：任何一個傻瓜都能寫出計算機可以理解的代碼，唯有寫出人類容易理解的代碼，才是優(yōu)秀的程序員。

歡迎工作一到五年的Java工程師朋友們加入Java架構開發(fā)：468947140

點擊鏈接加入群聊【Java-BATJ企業(yè)級資深架構】：https://jq.qq.com/?_wv=1027&k=5zMN6JB

本群提供免費的學習指導 架構資料 以及免費的解答

不懂得問題都可以在本群提出來 之后還會有職業(yè)生涯規(guī)劃以及面試指導

總結

以上是生活随笔為你收集整理的等重构完这系统，我就辞职的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。