重構(gòu)遺留軟件：從挑戰(zhàn)到機(jī)遇

本文講述了我們?nèi)绾翁幚硪粋€(gè)物流管理系統(tǒng)（OMS）的國(guó)際化，以及與新的電子商務(wù)平臺(tái)集成的挑戰(zhàn)。該系統(tǒng)開(kāi)發(fā)于2018年，旨在優(yōu)化一個(gè)蓬勃發(fā)展的電商的訂單準(zhǔn)備流程，并與不同的物流運(yùn)營(yíng)商高效集成。它使用PHP（Symfony）、MySQL、Socket.io和jQuery構(gòu)建，涵蓋從包裝到發(fā)貨的整個(gè)流程，包括訂單跟蹤、快遞員連接、標(biāo)簽生成和訂單準(zhǔn)備性能指標(biāo)等功能。

技術(shù)債務(wù)的累積

多年來(lái)，該系統(tǒng)運(yùn)行良好，但隨著業(yè)務(wù)發(fā)展，其局限性日益顯現(xiàn)。技術(shù)債務(wù)尤其令人擔(dān)憂，它影響了項(xiàng)目的多個(gè)層面。在技術(shù)基礎(chǔ)設(shè)施方面，該應(yīng)用程序運(yùn)行在過(guò)時(shí)的框架和基礎(chǔ)語(yǔ)言版本上：

• Symfony版本(4.0)并非長(zhǎng)期支持(LTS)版本，自2019年1月起停止接收安全更新。
• PHP 7.1也已結(jié)束生命周期，系統(tǒng)缺乏關(guān)鍵的安全更新。

除了過(guò)時(shí)的版本，項(xiàng)目在軟件開(kāi)發(fā)的基礎(chǔ)方面也存在嚴(yán)重缺陷：

• 缺乏或不足的測(cè)試: 缺乏自動(dòng)化測(cè)試（單元測(cè)試、集成測(cè)試和端到端測(cè)試）不僅阻礙了早期錯(cuò)誤的發(fā)現(xiàn)，還使任何修改都可能危及系統(tǒng)的穩(wěn)定性。
• 缺乏代碼標(biāo)準(zhǔn): 代碼庫(kù)沒(méi)有遵循任何已記錄的模式或標(biāo)準(zhǔn)，即使有，也與行業(yè)最佳實(shí)踐不符。這使得維護(hù)和項(xiàng)目中新開(kāi)發(fā)人員的加入都變得困難。
• 文檔不足: 現(xiàn)有文檔稀少且經(jīng)常不完整。這不僅影響了技術(shù)開(kāi)發(fā)，還影響了對(duì)代碼中實(shí)現(xiàn)的業(yè)務(wù)流程的理解。
• 版本控制不完善: Git歷史記錄缺乏解釋，提交粒度粗糙，消息也不遵循任何約定，缺乏對(duì)所做更改的背景信息。這使得理解代碼的演變和隨時(shí)間做出的決策變得困難。

技術(shù)債務(wù)的累積不僅對(duì)系統(tǒng)的穩(wěn)定性和安全性構(gòu)成威脅，還：

• 降低了新功能的開(kāi)發(fā)速度
• 增加了引入錯(cuò)誤的風(fēng)險(xiǎn)
• 增加了新成員加入團(tuán)隊(duì)的難度
• 增加了維護(hù)成本
• 使問(wèn)題診斷和解決變得復(fù)雜

結(jié)構(gòu)性限制

最初的架構(gòu)存在耦合問(wèn)題，嚴(yán)重影響了其靈活性和可擴(kuò)展性：

• 完全依賴于主電商平臺(tái): 該應(yīng)用程序無(wú)法獨(dú)立運(yùn)行，所有物流操作都直接依賴于電商平臺(tái)的數(shù)據(jù)和流程。這意味著主平臺(tái)的任何更改都可能破壞系統(tǒng)的功能。
• 共享數(shù)據(jù)庫(kù)導(dǎo)致性能問(wèn)題: 物流應(yīng)用程序和電商平臺(tái)使用相同的數(shù)據(jù)庫(kù)，這導(dǎo)致性能問(wèn)題，尤其是在任一應(yīng)用程序的負(fù)載高峰期。此外，此配置使權(quán)限管理變得復(fù)雜，因?yàn)閷?duì)數(shù)據(jù)庫(kù)的任何訪問(wèn)都可能危及其他系統(tǒng)的重要數(shù)據(jù)。
• 無(wú)法獨(dú)立運(yùn)行: 該應(yīng)用程序的設(shè)計(jì)只能與電商平臺(tái)一起運(yùn)行。這不僅限制了其可移植性，還阻礙了在隔離環(huán)境中進(jìn)行測(cè)試或遷移到其他平臺(tái)。其依賴項(xiàng)沒(méi)有得到適當(dāng)?shù)姆庋b，任何隔離嘗試都需要對(duì)整個(gè)系統(tǒng)進(jìn)行大規(guī)模且代價(jià)高昂的更改，主要類中沒(méi)有遵守單一責(zé)任原則（SRP）。
• 難以實(shí)現(xiàn)新功能: 缺乏對(duì)開(kāi)放/封閉原則（OCP）和Liskov替換原則（LSP）的遵守，極大地阻礙了系統(tǒng)的演進(jìn)。新功能需要修改現(xiàn)有代碼，增加了引入回歸的風(fēng)險(xiǎn)。此外，模塊之間的直接依賴使得遵循依賴倒置原則（DIP）幾乎不可能。

這些結(jié)構(gòu)性限制不僅降低了系統(tǒng)的可維護(hù)性和可擴(kuò)展性，還增加了與任何修改或演進(jìn)相關(guān)的風(fēng)險(xiǎn)，使應(yīng)用程序處于技術(shù)上脆弱和戰(zhàn)略上易受攻擊的狀態(tài)。

開(kāi)發(fā)管理和戰(zhàn)略一致性

最顯著的挑戰(zhàn)之一不僅是技術(shù)性的，也是戰(zhàn)略性的。盡管外部開(kāi)發(fā)在功能上是正確的，但在組織方面存在重大局限性：

• 與全球戰(zhàn)略脫節(jié): 開(kāi)發(fā)是孤立進(jìn)行的，沒(méi)有對(duì)公司內(nèi)部目標(biāo)和流程的完整了解。這導(dǎo)致了一些功能，盡管技術(shù)上是正確的，但并不總是符合業(yè)務(wù)的實(shí)際需求。
• 缺乏戰(zhàn)略優(yōu)先級(jí): 新功能的實(shí)施缺乏明確的評(píng)估和優(yōu)先級(jí)排序流程。沒(méi)有質(zhì)疑一個(gè)功能是否真正必要，是否是最佳實(shí)現(xiàn)方式，或者是否存在更有效的替代方案。
• 被動(dòng)式開(kāi)發(fā) vs. 主動(dòng)式開(kāi)發(fā): 開(kāi)發(fā)主要遵循被動(dòng)模式，解決直接需求，而沒(méi)有考慮長(zhǎng)期影響或與公司其他流程的潛在協(xié)同作用。
• 缺乏驗(yàn)證流程: 缺乏結(jié)構(gòu)化的審查和驗(yàn)證流程導(dǎo)致了一些功能，盡管可以運(yùn)行，但并不總是對(duì)最終用戶或公司的整體目標(biāo)提供最佳解決方案。

這種情況在長(zhǎng)期內(nèi)是不可持續(xù)的，因?yàn)樗?/p>

• 導(dǎo)致產(chǎn)品越來(lái)越偏離實(shí)際需求
• 阻礙了與公司其他系統(tǒng)和流程的集成
• 使關(guān)于產(chǎn)品的戰(zhàn)略決策變得復(fù)雜
• 限制了團(tuán)隊(duì)的創(chuàng)新和持續(xù)改進(jìn)能力

基本成本的影響

在本項(xiàng)目中，一個(gè)經(jīng)常被忽視但特別重要的方面是基本成本，我認(rèn)為這是軟件開(kāi)發(fā)中的一個(gè)關(guān)鍵概念，它指的是即使不添加新功能或進(jìn)行改進(jìn)，維持系統(tǒng)運(yùn)行所需的最低成本。

在我們的案例中，基本成本包括所有因需要維護(hù)過(guò)時(shí)的框架和語(yǔ)言版本、解決因技術(shù)債務(wù)累積而導(dǎo)致的緊急事件、管理與其他系統(tǒng)的依賴關(guān)系、適應(yīng)耦合的架構(gòu)以及對(duì)領(lǐng)域知識(shí)的了解不足而產(chǎn)生的費(fèi)用。所有這些都消耗了大量可用資源，直接影響了投資創(chuàng)新和持續(xù)改進(jìn)的能力。

雖然這個(gè)因素并不是促使我們決定內(nèi)部化開(kāi)發(fā)的決定性因素，但在項(xiàng)目的初步診斷中，它具有相當(dāng)大的影響力?；境杀就ǔＴ谠u(píng)估系統(tǒng)的可持續(xù)性時(shí)被忽略，但在本案例中，它清楚地表明當(dāng)前的策略在長(zhǎng)期內(nèi)是不可持續(xù)的。此外，正如我們?cè)诤罄m(xù)文章中將看到的，任何試圖維持現(xiàn)有結(jié)構(gòu)的嘗試都將隨著時(shí)間的推移成倍地增加基本成本。

有關(guān)基本成本概念及其重要性的更詳細(xì)解釋，建議參考Eduardo Ferro的原始文章。

轉(zhuǎn)折點(diǎn)：新的挑戰(zhàn)和戰(zhàn)略決策

在任何重構(gòu)項(xiàng)目中，都可以采用多種策略，并且經(jīng)常會(huì)遇到以下兩難選擇：絞殺者模式（strangler fig）或徹底重寫(xiě)（big bang rewrite）。

最初的技術(shù)決策是在同一個(gè)遺留項(xiàng)目中工作，采用絞殺者模式，這種方法包括開(kāi)發(fā)一個(gè)新的模塊或系統(tǒng)，逐步替換舊系統(tǒng)的部分。這種策略允許我們進(jìn)行并行更改，降低風(fēng)險(xiǎn)，并在構(gòu)建更堅(jiān)實(shí)的基礎(chǔ)以支持未來(lái)功能的同時(shí)保持當(dāng)前功能。

然而，從業(yè)務(wù)的角度來(lái)看，這種選擇對(duì)現(xiàn)有系統(tǒng)（該系統(tǒng)已投入運(yùn)行并履行其職能）構(gòu)成了過(guò)高的風(fēng)險(xiǎn)。我們決定避免觸碰現(xiàn)有項(xiàng)目，而是開(kāi)發(fā)一個(gè)獨(dú)立的應(yīng)用程序來(lái)滿足新的需求。

這種轉(zhuǎn)變導(dǎo)致我們對(duì)現(xiàn)有代碼庫(kù)進(jìn)行了分支，這是一個(gè)技術(shù)上可行但存在某些缺點(diǎn)的決定：

• 代碼庫(kù)的重復(fù)：現(xiàn)在需要維護(hù)兩個(gè)單獨(dú)的代碼庫(kù)。
• 數(shù)據(jù)庫(kù)分離：必須為每個(gè)系統(tǒng)復(fù)制和調(diào)整數(shù)據(jù)結(jié)構(gòu)。
• 基礎(chǔ)設(shè)施復(fù)制：需要部署獨(dú)立的服務(wù)器并為每個(gè)系統(tǒng)保證適當(dāng)?shù)目捎^察性。
• 團(tuán)隊(duì)的認(rèn)知負(fù)擔(dān)增加：所有這些重復(fù)都需要額外的努力來(lái)維護(hù)兩個(gè)系統(tǒng)之間的一致性，從而增加了團(tuán)隊(duì)的復(fù)雜性和錯(cuò)誤風(fēng)險(xiǎn)。

這種方法使我們能夠朝著獨(dú)立的解決方案前進(jìn)，確?，F(xiàn)有系統(tǒng)的穩(wěn)定性，同時(shí)開(kāi)發(fā)一個(gè)與新的戰(zhàn)略目標(biāo)相一致的項(xiàng)目。然而，必須詳細(xì)分析利弊，才能充滿信心地進(jìn)行規(guī)劃和應(yīng)對(duì)這一挑戰(zhàn)。此外，我們與業(yè)務(wù)層面達(dá)成了共識(shí)，即不擴(kuò)展功能，并在完成向新電子商務(wù)平臺(tái)的遷移之前嚴(yán)格控制項(xiàng)目的積壓工作。

結(jié)論和后續(xù)步驟

決定內(nèi)部化和重寫(xiě)遺留軟件從來(lái)都不是一件容易的事，尤其是在該軟件能夠完成其功能的情況下。“如果它能工作，就不要碰它”這句話將始終存在。然而，有時(shí)需要后退一步才能前進(jìn)兩步。

在本系列的后續(xù)文章中，我們將探討我們?nèi)绾螒?yīng)對(duì)這些挑戰(zhàn)，我們做出的技術(shù)和戰(zhàn)略決策，以及我們?nèi)绾螌⑦@些挑戰(zhàn)轉(zhuǎn)化為改進(jìn)和團(tuán)隊(duì)發(fā)展的機(jī)遇。

以上是從軟件遺產(chǎn)到戰(zhàn)略機(jī)遇：起點(diǎn)（一）的詳細(xì)內(nèi)容。更多信息請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！