舊系統不好用，叫IT人員「砍掉重練」做個新系統最快？最好再多想想！

編者按：面對遺留的老系統，人人都很不爽，都想推倒重來。但是要如何推倒重來呢？余晟是中國知名的程式工程師，曾任抓蝦網、銀杏泰克主力程式師，盛大創新院高級研究員，現任電商公司技術部總監。他最近發表了一篇對於「砍掉重練」的看法，或許值得我們參考。

上個月，有個以前的同事問我：「你在的時候，為什麼不把原來的系統都重做了，我們明明有實力啊。」

我說：「我們也做了很多事情嘛，系統穩定性、安全性、增加冗餘、理清各模組職責、API 通訊機制的建立、內部分層的整理。」

他說：「對，但我還是想知道，你為什麼不把系統重做了呢？」

於是我問：「我離職之後，後來似乎多投了不少人重做系統？結果怎麼樣呢？」

他想了想，說：「結果，結果就是做業務要同時操作三四套系統……」

 

「砍掉重練」的迷思

就我所見，把原有系統「推倒重來」的喜好不只程式師有，使用者更有。拿我幾年前的那份工作來說，剛入職老大們就來跟我討論系統重做的打算：需要多少人，多少錢，多長時間，能把原有系統推翻重來。

畢竟，大家每天都忍受舊系統的切膚之痛：速度慢、經常出錯、不安全、客戶抱怨、架構糟糕…… 所以都想拿出勁頭，來個乾脆的徹底解決。

這種心情可以理解，但在我任內「重做系統」這件事，一直沒有被提上日程，整個技術團隊所做的都是「改良」的工作。具體內容就像我上面說的：系統穩定性、安全性、增加冗餘、理清各模組職責、API 通訊機制的建立、內部分層的整理。這個選擇我有充分把握，而且在我看來，如果斷然 「推倒重來」，我未必能比繼任者做得更好，甚至可能更糟糕，因為「推倒重來」絕不是那麼簡單的事情。

眾所周知，軟體發展的難點之一就是控制複雜度。但是在不同的領域，複雜度有不同的表現。對於純網路業務，或者 IT 基礎架構來說，其複雜度在於軟體本身，架構的制定、類庫的選擇、撰寫程式碼的品質等等。

對於其它 IT 系統——尤其是公司迅速成長，業務不斷複雜化的 IT 系統——而言，其複雜度並不在於軟體本身，安全、性能、負載的問題都套用現成的 IT 解決方案，真正的複雜度來自系統承載的業務本身，比如最簡單的：系統裡有哪些單據，各種單據承載什麼資訊，用在什麼場景，這些單據是怎樣流轉的，各種單據存在怎樣的約束關係，出現異常情況應當如何處理才能保證業務資料的一致性……這些問題沒有準確而穩定的答案，IT 再怎樣努力也是白搭。

對於已經能規範運行的業務，或者是有經典解決方案的工作（比如財務、倉庫管理），這些知識都是現成的，可以直接拿來用。但對於新興領域、新興業務來說，往往不存在 「經典解決方案」。加上很多公司成長速度飛快，一開始並沒有構築好的 IT 基礎（其實是業務架構基礎）。

這些公司最典型的情況就是：業務概念混亂不清，業務邏輯層也是雜亂無章，很多系統裡乾脆把資料庫當作業務邏輯層（這可不是說笑，因為資料庫無法推脫責任了）。結果，混亂的業務邏輯依附於糟糕的 IT 系統，亂上加亂最終成了一鍋粥。對 IT 來說，已有業務的問題層出不窮，每次出問題都需要花費大量精力，尋找蛛絲馬跡來 「破案」；對業務來說，新增業務往往會影響到原有業務，但誰也不知道會不會影響，會如何影響。系統日漸龐大的另一面是內部日趨無序，複雜度和維護成本飛速增長，遠遠超過可控範圍。

吊詭的是，許多人的解決辦法不是針對問題的根本原因，評估業務複雜度、整理業務邏輯、整理業務關係，反而認為 「推倒重來」、新做一套系統就能解決。持這種觀點的人，通常對系統與業務的關係也有誤解。

對希望 「推倒重來」的人來說，系統和業務的關係，有點像車輛對人員：一輛車我開了一段時間覺得不好，就想換一輛車來開，這是很自然的。但是在資訊化深入工作各個角落的今天，系統和業務的關係遠不是 「車對人」 那麼疏遠，而更像 「心律調節器對人」，或者 「人造骨骼與肌肉」 的關係，已經如膠似漆纏在了一起，系統對業務的支援越多越廣（暫時不論品質），雙方糾纏得也就越緊密。更換心律調節器對人或者人造骨骼的難度，遠遠比換車的難度要大，所以需要慎重考慮，不能單純因為心律調節器對人 “不那麼好” 就輕率決定更換。對系統來說，也是如此。

 

怎麼評估有沒有本錢砍掉重練？

如果要對基礎不好的遺留系統做脫胎換骨的改造，我有幾點經驗可以參考：

第一，一定要有非常優秀的業務人員和開發人員。

對業務人員來說，不但要熟悉自己手頭的操作，還必須明白操作背後的邏輯，並且需要超越本職工作，能從全域角度來思考自己的業務（有時甚至要讓自己操作更複雜，來提高系統安全性等收益），這樣才能真正把握住業務的複雜度。

對開發人員來說，要能夠完整理解領域知識，同時必須有高超的程式設計能力來應對遺留代碼，敢於出手而不是畏縮不前，謹慎出手而不是貿然行動——如果原有系統開發人員的技術能力可以打 30 分，全新開發系統的技術要求是 60 分，那麼要成功改造遺留系統的技術人員，往往需要有 80 以上的分數才能勝任。

第二，“推倒重來” 往往不如 “逐步改良”。

所謂 “逐步改良”，指的是大家先通過討論確認未來系統的設計藍圖，然後需要開發用於過渡的介面層。於是，新開發的模組一定要嚴格按照新的規範開發（這也就是我說的 “理清各模組職責、API 通訊機制的建立、內部分層的整理”），同時通過介面層與原有系統對接，原有的模組則在理清業務邏輯的情況下，按需切出合適的介面，逐部分在測試通過的情況下進行遷移。最終，新的系統是像拼圖一樣慢慢拼出來到最後一天才成型的，而不是平底蓋樓造起來的。

在這個過程中，最關鍵的是找到合適的切入點，搭建出合適的介面或者介面層。這些工作就像蓋房子的腳手架，哪怕之後不會用到，中途也不能省略，還必須仔細對待。當然，這是一個考驗人的工作——我曾經遇到過資料庫事務裡跨庫連表的查詢，這個糟糕的設計嚴重阻礙了單資料庫實例拆分成多實例的進展，回想起來真是如噩夢一般。