重建遺留軟體：從挑戰(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也已結(jié)束生命週期，系統(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ā)速度
• 增加了引入錯誤的風險
• 增加了新成員加入團隊的難度
• 增加了維護成本
• 讓問題診斷與解決變得複雜

結(jié)構性限制

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

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

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

開發(fā)管理與策略一致性

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

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

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

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

基本成本的影響

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

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

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

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

轉(zhuǎ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ā)一個獨立的應用程式來滿足新的需求。

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

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

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

結(jié)論與後續(xù)步驟

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

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

以上是從軟體遺產(chǎn)到策略機會：起點（一）的詳細內(nèi)容。更多資訊請關注PHP中文網(wǎng)其他相關文章！