[[151700]]

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

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

　　他說：“對，但我還是想知道，你為什么不把系統重做了呢?”

　　于是我問：“我離職之后，后來似乎多投了不少人重做系統?結果怎么樣呢?”

　　他說：“結果，結果就是做業務要同時操作三四套系統……”

　　就我所見，把原有系統 “推倒重來” 的喜好不只程序員有，使用者更有。拿我幾年前的那份工作來說，剛入職老大們就來跟我討論系統重做的打算：需要多少人，多少錢，多長時間，能把原有系統推翻重來。畢竟大家每天都忍受切膚之痛：速度慢、經常出錯、不安全、客戶抱怨、架構糟糕…… 所以都想拿出 “敢叫日月 換新天” 的勁頭，來個干脆的徹底解決。

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

　　眾所周知，軟件開發的難點之一就是控制復雜度。但是在不同的領域，復雜度有不同的表現。對于純互聯網業務，或者 IT 基礎架構來說，其復雜度在于軟件本身，架構的制定、類庫的選擇、編碼的質量等等。對于其它 IT 系統——尤其是公司迅速成長，業務不斷復雜化的 IT 系統——而言，其復雜度并不在于軟件本身，安全、性能、負載的問題都套用現成的 IT 解決方案，真正的復雜度來自系統承載的業務本身，比如最簡單的：系統里有哪些單據，各種單據承載什么信息，用在什么場景，這些單據是怎樣流轉的，各種單據存在怎樣的約束關系，出現異常情況應當如何處理才能保證業務數據的一致性……這些問題沒有準確而穩定的答案，IT 再怎樣努力也是白搭。

　　對于已經能在線下規范運行的業務，或者是有經典解決方案的工作(比如財務、倉庫管理)，這些知識都是現成的，可以直接拿來用。但對于新興領域、新興業務來說，往往不存在 “經典解決方案”。加上很多公司成長速度飛快，一開始并沒有構筑好的 IT 基礎(其實是業務架構基礎)。典型的情況就是：業務概念混亂不清，業務邏輯層也是雜亂無章，很多系統里干脆把數據庫當作業務邏輯層(這可不是說笑，因為數據庫無法推脫責任了)。結果，混亂的業務邏輯依附于糟糕的 IT 系統，亂上加亂最終成了一鍋粥。對 IT 來說，已有業務的問題層出不窮，每次出問題都需要花費大量精力，尋找蛛絲馬跡來 “破案”;對業務來說，新增業務往往會影響到原有業務，但誰也不知道會不會影響，會如何影響。系統日漸龐大的另一面是內部日趨無序，復雜度和維護成本飛速增長，遠遠超過可控范圍。

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

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

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

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

　 　對業務人員來說，不但要熟悉自己手頭的操作，還必須明白操作背后的邏輯，并且需要超越本職工作，能從全局角度來思考自己的業務(有時甚至要讓自己操作更 復雜，來提高系統安全性等收益)，這樣才能真正把握住業務的復雜度。對開發人員來說，要能夠完整理解領域知識，同時必須有高超的編程能力來應對遺留代碼， 敢于出手而不是畏縮不前，謹慎出手而不是貿然行動——如果原有系統開發人員的技術能力可以打 30 分，全新開發系統的技術要求是 60 分，那么要成功改造遺留系統的技術人員，往往需要有 80 以上的分數才能勝任。

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

　 　所謂 “逐步改良”，指的是大家先通過討論確認未來系統的設計藍圖，然后需要開發用于過渡的接口層。于是，新開發的模塊一定要嚴格按照新的規范開發(這也就是我 說的 “理清各模塊職責、API 通訊機制的建立、內部分層的整理”)，同時通過過渡的接口層與原有系統對接，原有的模塊則在理清業務邏輯的情況下，按需切出合適的接口，逐部分在測試通過 的情況下進行遷移。最終新的系統是像拼圖一樣慢慢拼出來到最后一天才成型的，而不是平底蓋樓造起來的。在這個過程中，最關鍵的是找到合適的切入點，搭建出 合適的接口或者接口層。這些工作就像蓋房子的腳手架，哪怕之后不會用到，中途也不能省略，還必須仔細對待。當然，這是一個考驗人的工作——我曾經遇到過數 據庫事務里跨庫連表的查詢，這個糟糕的設計嚴重阻礙了單數據庫實例拆分成多實例的進展，回想起來真是如噩夢一般。

　　如果你對改造遺留系統有自己的見解，或者在這個過程中有什么有意思的經歷，歡迎留言給我。

　　最后推薦一本有意思的書。其實不管是軟件開發還是社會變革，對于不喜歡的現狀，大家往往喜歡來個 “干脆”、“徹底” 的解決方案，但真正成功的往往不是這些方案。在第二次世界大戰結束時，世界上到底發生了哪些事情，遇到了哪些問題，又是怎樣重建社會秩序的呢?廣西師大《理想國》叢書第 9 冊《零年：1945 現代世界誕生的時刻》，用翔實的文筆全面記錄了 “終戰” 之后的情景，許多畫面相信會讓讀者大吃一驚——很多時候 “文明” 堪稱被打回原形，“零年” 這個名字可謂名副其實。

　　編者按：面對遺留的老系統，人人都很不爽，都想推倒重來。但是要如何推倒重來呢?聽聽余晟的看法，本文首發于他的微信公眾號余晟以為(yurii-says)

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

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

　　他說：“對，但我還是想知道，你為什么不把系統重做了呢?”

　　于是我問：“我離職之后，后來似乎多投了不少人重做系統?結果怎么樣呢?”

　　他說：“結果，結果就是做業務要同時操作三四套系統……”

　　就我所見，把原有系統 “推倒重來” 的喜好不只程序員有，使用者更有。拿我幾年前的那份工作來說，剛入職老大們就來跟我討論系統重做的打算：需要多少人，多少錢，多長時間，能把原有系統推翻重來。畢竟大家每天都忍受切膚之痛：速度慢、經常出錯、不安全、客戶抱怨、架構糟糕…… 所以都想拿出 “敢叫日月 換新天” 的勁頭，來個干脆的徹底解決。

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

　　眾所周知，軟件開發的難點之一就是控制復雜度。但是在不同的領域，復雜度有不同的表現。對于純互聯網業務，或者 IT 基礎架構來說，其復雜度在于軟件本身，架構的制定、類庫的選擇、編碼的質量等等。對于其它 IT 系統——尤其是公司迅速成長，業務不斷復雜化的 IT 系統——而言，其復雜度并不在于軟件本身，安全、性能、負載的問題都套用現成的 IT 解決方案，真正的復雜度來自系統承載的業務本身，比如最簡單的：系統里有哪些單據，各種單據承載什么信息，用在什么場景，這些單據是怎樣流轉的，各種單據存在怎樣的約束關系，出現異常情況應當如何處理才能保證業務數據的一致性……這些問題沒有準確而穩定的答案，IT 再怎樣努力也是白搭。

　　對于已經能在線下規范運行的業務，或者是有經典解決方案的工作(比如財務、倉庫管理)，這些知識都是現成的，可以直接拿來用。但對于新興領域、新興業務來說，往往不存在 “經典解決方案”。加上很多公司成長速度飛快，一開始并沒有構筑好的 IT 基礎(其實是業務架構基礎)。典型的情況就是：業務概念混亂不清，業務邏輯層也是雜亂無章，很多系統里干脆把數據庫當作業務邏輯層(這可不是說笑，因為數據庫無法推脫責任了)。結果，混亂的業務邏輯依附于糟糕的 IT 系統，亂上加亂最終成了一鍋粥。對 IT 來說，已有業務的問題層出不窮，每次出問題都需要花費大量精力，尋找蛛絲馬跡來 “破案”;對業務來說，新增業務往往會影響到原有業務，但誰也不知道會不會影響，會如何影響。系統日漸龐大的另一面是內部日趨無序，復雜度和維護成本飛速增長，遠遠超過可控范圍。

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

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

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

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

　 　對業務人員來說，不但要熟悉自己手頭的操作，還必須明白操作背后的邏輯，并且需要超越本職工作，能從全局角度來思考自己的業務(有時甚至要讓自己操作更 復雜，來提高系統安全性等收益)，這樣才能真正把握住業務的復雜度。對開發人員來說，要能夠完整理解領域知識，同時必須有高超的編程能力來應對遺留代碼， 敢于出手而不是畏縮不前，謹慎出手而不是貿然行動——如果原有系統開發人員的技術能力可以打 30 分，全新開發系統的技術要求是 60 分，那么要成功改造遺留系統的技術人員，往往需要有 80 以上的分數才能勝任。

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

　 　所謂 “逐步改良”，指的是大家先通過討論確認未來系統的設計藍圖，然后需要開發用于過渡的接口層。于是，新開發的模塊一定要嚴格按照新的規范開發(這也就是我 說的 “理清各模塊職責、API 通訊機制的建立、內部分層的整理”)，同時通過過渡的接口層與原有系統對接，原有的模塊則在理清業務邏輯的情況下，按需切出合適的接口，逐部分在測試通過 的情況下進行遷移。最終新的系統是像拼圖一樣慢慢拼出來到最后一天才成型的，而不是平底蓋樓造起來的。在這個過程中，最關鍵的是找到合適的切入點，搭建出 合適的接口或者接口層。這些工作就像蓋房子的腳手架，哪怕之后不會用到，中途也不能省略，還必須仔細對待。當然，這是一個考驗人的工作——我曾經遇到過數 據庫事務里跨庫連表的查詢，這個糟糕的設計嚴重阻礙了單數據庫實例拆分成多實例的進展，回想起來真是如噩夢一般。

　　如果你對改造遺留系統有自己的見解，或者在這個過程中有什么有意思的經歷，歡迎留言給我。