從簡單的功能最佳化到複雜的架構升級，系統重構往往伴隨著高昂的時間成本和技術挑戰。本文透過一個生動的做菜場景，深入淺出地解釋了系統重構的重要性和必要性。
———— / BEGIN / ————
相信在產品經理的職業生涯中，大家不止一次聽過系統重構這個詞。
而且所有產品經理都經歷過這樣的魔幻時刻：明明只是加個篩選條件，技術評估卻要3個月；想最佳化某個功能按鈕，卻被告知整個頁面都要重寫。
一問原因：因為要系統重構！
那到底什麼是重構呢？
如果用一個我親身經歷過的例子來解釋重構的重要意義就是：
我當年所在某電商平臺在一次促銷活動時，導致每秒峰值訂單突破5000萬時，訂單系統響應速度從200ms驟升至2秒，注意是每單哦！
最後一番排查發現：優惠計算模組與庫存模組存在迴圈呼叫，核心業務邏輯與日誌模組深度耦合。
想象這樣的場景：炒鍋師傅（優惠模組）每做一份宮保雞丁，都要跑到倉庫（庫存系統）確認花生庫存，再折返調料臺（日誌系統）記錄操作日誌。高峰期這樣的折返跑，不出餐慢才是奇蹟。
同過這個做菜的例子大家很容易理解，這並不是因為軟體設計失誤，而是廚房（系統）擴張後的必然代價，單多了你就要最佳化的工序，要麼加人要麼提前做準備，相信沒有人會去說廚師你怎麼怎麼樣對吧？
不過很多時候，在我做諮詢走訪很多公司時，第一時間這個團隊的資訊化負責人的結論都是會把這個問題甩到“初代”產品經理身上，聲稱是“初代”系統的產品經理的設計不合理所導致了今天的一切。
但是我想說：重構系統是不可避免的！初期就沒有幾個客人的時候你要做一個航母出來也沒有用啊？
那今天我就給大家盤點一下重構的觸發條件（避免在規劃會上被甩鍋）：
【產品驅動】功能疊加困境：新需求開發週期超過3個月
【大白話解讀】你是一家賣燒烤的店，當某天老闆讓你推出酸菜魚的時候，你要做的就是需要重建灶臺，先把一部分烤爐改成煤氣灶。
【產品驅動】協作效率低下：跨團隊需求需修改5個以上模組，這背後往往是領域劃分不到位。
【大白話解讀】三個廚師擠在一個灶臺炒菜，你覺得會不會打架？
【技術驅動】系統性能瓶頸：核心介面成功率低於99%
【大白話解讀】相當於廚房出餐錯誤率超過10%
那我們要如何處理系統重構呢？
即時上按照現在企業的要求：重構就像在一家正常營業的餐廳去升級後廚——客人們照常吃著火鍋，後廚卻在悄然更換排風系統。
所以要求我們決不能停機！為此具體的執行步驟可以定義為下面的三大部分：
Step1：先搭臨時灶臺（顧舊立新）
在後廚角落搭建一個新的煤氣灶，保持老系統不再迭代，在旁邊根據新的產品規劃重新設計整個功能並實現。
Step2：食材統一分裝（介面翻譯層）
老顧客依然要吃到熟悉的”麻辣香鍋”，即便後廚已經改用智慧炒菜機。
我們知道很多時候在重構的時候由於新的方案的應用，比如使用者希望取消早已經不用的某個欄位，很多老系統的互動還是用生成一個檔案的形式定時去查詢（很多銀行系統現在還是這樣）。
注意這個時候我們要做的是必須保證提供的資料消費方式和命名方式都是之前的（比如之前叫userID），我們要做的是必須額外建設一個新的翻譯模組，把所有新的資料格式與介面翻譯成之前的模式，這麼做的最重要一點是，避免當某天下游報錯的時候，別人可以直接把一本糊塗賬扔到你頭上，都是因為你重構系統導致的，我資料都亂了（別問我怎麼知道的，血和淚換來的）。
Step3：動線魔法改造（資料雙寫+灰度釋出）
就像在傳菜通道加裝自動分揀機，先讓新模組處理5%的流量，同時保持老系統運轉。當新模組的到達率穩定在99.97%後，才逐步關閉老舊程式碼。
所以總結一下就是：
-
蓋新屋子：保持老房子對外輸出不變，在旁邊另起爐灶；
-
保持對外輸出不變：翻譯成現有介面的輸出格式：欄位叫法/欄位型別/消費方式；
-
灰度切換流量：逐步將老系統的流量切換至新系統，最後關停老系統；
當然在文章的最後結尾，必須給大家補充一個我的經驗教訓：
重構這件事在任何一家公司都是出力不討好的事，活又多，風險又高，如果你不幸接手了，那你要做的必須要讓你的業務可感知，也就是透過重構給業務側帶來新的業務價值提升（速讀/解決舊歷史問題/解決之前業務不能實現的需求），否則重構的過程就將無比艱難！
下次再聽到”需要重構”時，請記住：這不是在否定你的設計，而是邀請你參與指揮一場廚房革命。畢竟，在數字化生存時代，不會用架構思維武裝自己的產品經理，終將成為被重構的物件。
———— / E N D / ————
本文來自微信公眾號：三爺茶館，作者：三爺茶館
