[[155470]]

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

我說：“我們也做了很多事情嘛，系統(tǒng)穩(wěn)定性、安全性、增加冗余、理清各模塊職責(zé)、API 通訊機(jī)制的建立、內(nèi)部分層的整理。”

他說：“對，但我還是想知道，你為什么不把系統(tǒng)重做了呢？”

于是我問：“我離職之后，后來似乎多投了不少人重做系統(tǒng)？結(jié)果怎么樣呢？”

他說：“結(jié)果，結(jié)果就是做業(yè)務(wù)要同時操作三四套系統(tǒng)……”

就我所見，把原有系統(tǒng) “推倒重來” 的喜好不只程序員有，使用者更有。拿我?guī)啄昵暗哪欠莨ぷ鱽碚f，剛?cè)肼毨洗髠兙蛠砀矣懻撓到y(tǒng)重做的打算：需要多少人，多少錢，多長時間，能把原有系統(tǒng)推翻重來。畢竟大家每天都忍受切膚之痛：速度慢、經(jīng)常出錯、不安全、客戶抱怨、架構(gòu)糟糕…… 所以都想拿出 “敢叫日月 換新天” 的勁頭，來個干脆的徹底解決。

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

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

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

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

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

如果要對基礎(chǔ)不好的遺留系統(tǒng)做脫胎換骨的改造，我有幾點經(jīng)驗可以參考：

***，一定要有非常優(yōu)秀的業(yè)務(wù)人員和開發(fā)人員。

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

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

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

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

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