堪比刪庫跑路，重構完這系統，我就提離職！

Part.1

爲何程序員一言不合就重構代碼？

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

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

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

如下的場景是否是很熟悉：

測試：這麼小的功能，你爲何改動300多個文件？

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

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

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

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

產品：你又在弄重構？我這還有一大堆需求沒人開發。

開發：我這的重構系統也很是重要的。

產品：哪裏重要了？你浪費這麼多人力重構，用戶也看不出來系統有什麼變化，搞很差還弄壞老功能。求求你別重構了。

開發：我……

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

只是重構是個大坑，不當心就掉坑裏。

Part.2

「等重構完這個系統，我就提離職。」龍哥說。

因爲核心系統初期設計不當，權責界限模糊，只要沾點邊的代碼都往上堆，形成系統過於龐大，邏輯混亂，一出現問題，形成核心業務癱瘓。

過老過大過中心的系統像個不定時炸彈，吃過幾回虧後，業務組決定拔掉這隱患：將系統重構，按照業務處理邏輯拆分紅各功能單一的子系統，下降耦合度。

大夥把這事看成季度最重要的計劃來開展：熱火朝天的開會劃分系統，梳理代碼邏輯，安排測試，聲明注意事項。

各人領了任務後，開始埋頭苦幹起來。

可是重構系統像從一個大迷宮捋線路，捋的過程耗費巨大，並且極易遺漏。產品後來提的新需求直接在重構後的系統裏新增。開發團隊進入惡性循環：新增功能有的人在老系統分支改，有人在新的改，致使提交的代碼分支混亂，搭建過程緩慢，計劃的任務delay，最後測試人員發現不少遺漏點，又返工重構。

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

上線時間從9月份推遲到12月份，再到年後，最終來年6月份系統才上線完成，耗時一年多。

每一個人被重構折磨得疲憊不已，還短期看不出來效果，可已經投入人力物力，你們只好硬着頭皮往下走。

後來你們已經想不起當初爲何要重構，到底要重構到什麼樣子，只想着這重構什麼時候到頭，何時才能解放。

從重構半年時開始有人離職，到上線時僅剩一個原項目組的產品，他說這項目終於結束，我也該走了。

Part.3

上面的重構沒有合理的項目規劃，還犯了重構的大忌：邊重構代碼邊新增功能，這樣至關於將原系統推翻重作，風險極大。

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

1. 遵循「兩頂帽子」重構原則

在重構時，兩個不一樣的操做分開進行：重構代碼和新增功能。

先在不改變原系統功能的基礎上修改現有代碼的設計，這樣採用原有的測試方法能夠輕鬆地驗證這些修改的正確性。

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

上述例子裏，業務組邊重構邊在上面新開發功能，給測試人員的壓力巨大，原有的測試方法全不適用，增長迴歸測試工做量。

2. 使用「小步快跑」的重構策略

重構避免使用「大布局」規劃項目進程，若是從整理需求、設計接口、開發聯調、測試上線，經歷幾個月的時間，若是其間有問題，整個團隊又得人仰馬翻地去調整方向，試錯成本太高。

「小布快跑」是讓咱們重構時只關注一個問題點，只解決這一個問題。小改動，小局部優化，耗時短，見效快。

這便須要咱們將重構看成一個習慣，融入在每一次代碼修改中。

3. 測試驅動開發

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

正確的重構姿式是將測試融入在每一次重構中，小步快跑，修改一塊代碼便自測這塊，等調通後再繼續往下走。重構有風險，開發測試兩手捉。

《重構》一書裏說道：任何一個傻瓜都能寫出計算機能夠理解的代碼，惟有寫出人類容易理解的代碼，纔是優秀的程序員。