重構遺留軟件：從挑戰(zhàn)到機遇

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

技術債務的累積

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

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

除了過時的版本，項目在軟件開發(fā)的基礎方面也存在嚴重缺陷：

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

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

• 降低了新功能的開發(fā)速度
• 增加了引入錯誤的風險
• 增加了新成員加入團隊的難度
• 增加了維護成本
• 使問題診斷和解決變得復雜

結構性限制

最初的架構存在耦合問題，嚴重影響了其靈活性和可擴展性：

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

這些結構性限制不僅降低了系統(tǒng)的可維護性和可擴展性，還增加了與任何修改或演進相關的風險，使應用程序處于技術上脆弱和戰(zhàn)略上易受攻擊的狀態(tài)。

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

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

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

這種情況在長期內(nèi)是不可持續(xù)的，因為它：

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

基本成本的影響

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

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

雖然這個因素并不是促使我們決定內(nèi)部化開發(fā)的決定性因素，但在項目的初步診斷中，它具有相當大的影響力。基本成本通常在評估系統(tǒng)的可持續(xù)性時被忽略，但在本案例中，它清楚地表明當前的策略在長期內(nèi)是不可持續(xù)的。此外，正如我們在后續(xù)文章中將看到的，任何試圖維持現(xiàn)有結構的嘗試都將隨著時間的推移成倍地增加基本成本。

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

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

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

最初的技術決策是在同一個遺留項目中工作，采用絞殺者模式，這種方法包括開發(fā)一個新的模塊或系統(tǒng)，逐步替換舊系統(tǒng)的部分。這種策略允許我們進行并行更改，降低風險，并在構建更堅實的基礎以支持未來功能的同時保持當前功能。

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

這種轉變導致我們對現(xiàn)有代碼庫進行了分支，這是一個技術上可行但存在某些缺點的決定：

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

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

結論和后續(xù)步驟

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

在本系列的后續(xù)文章中，我們將探討我們?nèi)绾螒獙@些挑戰(zhàn)，我們做出的技術和戰(zhàn)略決策，以及我們?nèi)绾螌⑦@些挑戰(zhàn)轉化為改進和團隊發(fā)展的機遇。

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