選擇重寫：噩夢的開始

復(fù)雜繁多的應(yīng)用程序往往牽一發(fā)動全身，當(dāng)你想重做部分應(yīng)用時，發(fā)現(xiàn)其他的應(yīng)用程序也會受到影響。

[[315509]]

更糟糕的是，當(dāng)你更改代碼前試圖編寫單元測試時，發(fā)現(xiàn)該代碼最初并沒有設(shè)計成可測試的代碼。所以，在進行了種種掙扎和嘗試后，你可能就會把這個應(yīng)用程序凍結(jié)起來，再也不想碰它了......

那么，有沒有一種辦法既能更改無法維護的代碼，又能使局面不那么糟糕呢?

我們知道，更改代碼存在一定風(fēng)險，而重構(gòu)成本又太高。在這種情況下，從頭開始重新編寫代碼看起來是個不錯的主意。

按照這個思路，接下來會發(fā)生什么?

1. 你在重寫現(xiàn)有應(yīng)用程序的同時，與管理層討論一段時間內(nèi)停用新功能。
2. 重寫一個包含現(xiàn)在 應(yīng)用程序 功能的新程序大約耗時 6 個月。
3. 幾個月后，出現(xiàn)了一個令人討厭的 bug，并且這個 bug 必須在舊代碼中修復(fù)。因此，你又修補了舊代碼和新代碼。
4. 再過幾個月，公司將一些新功能交付給了客戶。但新功能必須用舊代碼才能實現(xiàn)，因為新版本尚未準(zhǔn)備好。你不僅要再次返回到舊代碼中，還要添加一個 TODO 以便這些新功能在新版本中實現(xiàn)。
5. 轉(zhuǎn)眼 5 個月過去了，你意識到項目可能要延遲，舊應(yīng)用程序遠(yuǎn)比想象得要棘手。
6. 7 個月過去了，你開始測試新版本，QA 質(zhì)量檢查發(fā)現(xiàn)了很多需要修復(fù)的問題。
7. 9 個月后，公司再也受不了“不開發(fā)功能”。領(lǐng)導(dǎo)開始不滿，你為此身心俱疲。你一邊掙扎著更改舊代碼，一邊加快速度重寫代碼。
8. 最終結(jié)果是，你做出了兩個系統(tǒng)。擺脫舊代碼還需要一段時間，因為新代碼還沒準(zhǔn)備好。每個功能都需要在新系統(tǒng)和舊系統(tǒng)中實現(xiàn)兩次。

最終，我選擇扼殺

我現(xiàn)在的項目，就是在處理這個問題。我們內(nèi)部有兩個并行工作的系統(tǒng)：cart(舊系統(tǒng))和 booking(新系統(tǒng))。實際上，booking 應(yīng)該替換掉 cart。

該項目始于三年前，但三年過去了，項目仍然未完成。

booking 總體上講要優(yōu)于 cart，但并不是說所有方面都比 cart 出色，一些購買流程會使用 booking，但仍有很多流程沿用 cart。

現(xiàn)在，由于新舊系統(tǒng)并行工作，所以新功能的實現(xiàn)時間是原來的兩倍。有趣的是，由于最初的設(shè)計目的并不是為了支持我們想要的新功能，而是因為 booking 有些過時了，所以才會建議“適當(dāng)重寫 cart 系統(tǒng)。”

如果按照這個思路，接下來幾個月，我們可能要讓兩個系統(tǒng)并行運行。顯然，這不是個好辦法，我還知道另外一種能有效解決系統(tǒng)問題的辦法，就是“扼殺”。

如何“扼殺”舊代碼庫

方法很簡單：逐步刪除舊的代碼庫，使用新的代碼庫。

具體操作如下：

• 讓新代碼充當(dāng)舊代碼的代理服務(wù)器(proxy)。用戶使用新系統(tǒng)，新系統(tǒng)重定向到舊系統(tǒng)。
• 在新代碼庫重新實現(xiàn)每步操作，這種操作在終端用戶看來沒有任何變化。
• 通過讓用戶使用新功能來逐漸淡化舊代碼。刪除舊的、未使用的代碼。

實際操作

來說說我們的系統(tǒng)，我們有一個用于處理付款的 cart模塊。

我們嘗試重寫，想法是創(chuàng)建一個新的、比 cart 更好的 booking 支付方式。但是這個項目沒有 100%交付，因為重寫工作耗費了太多時間，我們不得不在舊 cart 系統(tǒng)上開發(fā)新功能。

最終，我們還是創(chuàng)建了兩個模塊。

讓我們再試一次，這次我們來“扼殺”cart 模塊。與上一種方式不同的是，這次我們引入新 booking 模塊作為代理服務(wù)器。

設(shè)置起來很容易。很快，我們可以在不重復(fù)付款處理邏輯的情況下將其交付生產(chǎn)。然后，逐步地，我們可以開始將付款邏輯遷移到新的 booking 模塊。

在遷移邏輯時，我們擺脫了 cart 模塊上未使用的代碼。這個過程可能會需要一段時間，但我們正逐漸摒棄掉舊的、難以維護的 cart，開始應(yīng)用新的、更好的 booking。

結(jié)束語

這樣做最好的地方是可以解決重寫期間無法交付新功能的問題。使用這種技術(shù)，無需復(fù)制代碼，更無需實現(xiàn)兩次新功能。另外，你需要盡快將新系統(tǒng)投入使用，更快地獲得反饋，很大程度減少工作量并且降低把事情搞砸的風(fēng)險。

最后，你可以有條不紊地進行重寫，而無需將代碼凍結(jié) 6 個月。盡管“扼殺”可能帶有暴力色彩，但這種隱喻恰恰描述了慢慢擺脫舊系統(tǒng)的方法，與完全轉(zhuǎn)換相比，這樣做的風(fēng)險較小。當(dāng)舊代碼實在難以使用時，這可能是邁向更好設(shè)計的第一步。

如果你在從事領(lǐng)域驅(qū)動設(shè)計(DDD)，我建議你采用這種方法逐步淘汰舊系統(tǒng)。

你可以將舊系統(tǒng)視為黑匣子，創(chuàng)建一個 Bubble Context ，在其中應(yīng)用部署 DDD 原理。Bubble Context 與舊系統(tǒng)進行交互。逐漸地，新功能將在不斷增長的 Bubble context 中實現(xiàn)。同時，業(yè)務(wù)中用到舊系統(tǒng)的機會也越來越少，直到有一天，你可以徹底關(guān)閉舊系統(tǒng)。