等重構完這系統，我就辭職

作者五五

白天搬磚，晚上砌夢想。相信每個人有故事，程式設計師更是有許多事故，書寫最接地氣的程式設計師故事。

part.1

為什麼程式設計師一言不合就重構**？

當你看到前任寫成一團毛球的**塊；新增幾行**需先捋半天邏輯的超級大函式；好不容易在迷宮裡找到方向，小心翼翼地新增上新**，卻將別的呼叫系統給弄垮時；還有執行緩慢的老系統……

此時程式設計師只有兩個選擇：要麼忍，要麼重構。

忍是有極限的，重構的「三次法則」表示：程式設計師第一次看到亂**可以繞過去，先將手上的**堆好；第二次再碰上這塊，心裡雖反感但再一次勉強繞過；第三次肯定忍不住動手。

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

測試：這麼小的功能，你為什麼改動300多個檔案？

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

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

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

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

開發：我這的重構系統也非常重要的。

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

開發：我……

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

part.2

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

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

大夥把這事當作季度最重要的計畫來開展：熱火朝天的開會劃分系統，梳理**邏輯，安排測試，宣告注意事項。

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

但是重構系統像從乙個大迷宮捋線路，捋的過程耗費巨大，而且極易遺漏。產品後來提的新需求直接在重構後的系統裡新增。開發團隊進入惡性迴圈：新增功能有的人在老系統分支改，有人在新的改，導致提交的**分支混亂，搭建過程緩慢，計畫的任務delay，最後測試人員發現很多遺漏點，又返工重構。

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

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

每個人被重構折磨得疲憊不已，還短時間看不出來效果，可已經投入人力物力，大家只好硬著頭皮往下走。

後來大家已經想不起當初為什麼要重構，到底要重構到什麼樣子，只想著這重構何時到頭，什麼時候才能解放。

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

part.3

上面的重構沒有合理的專案規劃，還犯了重構的大忌：邊重構**邊新增功能，這樣相當於將原系統推翻重做，風險極大。

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

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

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

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

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

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

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

重構避免使用「大布局」規劃專案程序，如果從整理需求、設計介面、開發聯調、測試上線，經歷幾個月的時間，如果其間有問題，整個團隊又得人仰馬翻地去調整方向，試錯成本過高。

「小布快跑」是讓我們重構時只關注乙個問題點，只解決這乙個問題。小改動，小區域性優化，耗時短，見效快。

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

3.測試驅動開發

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

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

《重構》一書裡說道：任何乙個傻瓜都能寫出計算機可以理解的**，唯有寫出人類容易理解的**，才是優秀的程式設計師。

等重構完這系統，我就辭職

part.1 為什麼程式設計師一言不合就重構 當你看到前任寫成一團毛球的 塊 新增幾行 需先捋半天邏輯的超級大函式 好不容易在迷宮裡找到方向，小心翼翼地新增上新 卻將別的呼叫系統給弄垮時 還有執行緩慢的老系統 此時程式設計師只有兩個選擇 要麼忍，要麼重構。忍是有極限的，重構的 三次法則 表示 程式設...

Verizon報告 物聯網未來十年將重構這八大行業

物聯網在今天已經對各行各業產生影響，他們都在通過建立物聯網來調整自身的未來戰略和商業模式。通過 一張連線萬物的網路 各個行業可以溝通整合成你難以想象的樣子。當監控的風速顯示達到5英里每小時，聯網的風車會開始自動發電。在2015 2025年期間，將有3801億美元投入智慧型電網的建設中。當農作物種植土...

設計模式學習（六） 重構與模式，推薦書籍（完）

備註 1.模式常常組合使用，共同解決問題。2.模式是特定場景下優雅的解決方案，因此場景很關鍵。在軟體設計中，特定的場景可能是顯而易見的，可能是隱而不現的，有時甚至是設計者有意創造的。因此使用模式時，對問題的分析至關重要。3.模式的使用是有先後之分的。4.dp書中所給的結構圖僅僅是模式可能的實現方式之...