重建遺留軟體：從挑戰(zhàn)到機(jī)會(huì)

本文講述了我們?nèi)绾翁幚硪粋€(gè)物流管理系統(tǒng)（OMS）的國(guó)際化，以及與新的電子商務(wù)平臺(tái)整合的挑戰(zhàn)。該系統(tǒng)開發(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ù)債的累積

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

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

除了過時(shí)的版本，專案在軟體開發(fā)的基礎(chǔ)方面也存在嚴(yán)重缺陷：

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

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

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

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

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

• 完全依賴主電商平臺(tái): 該應(yīng)用程式無法獨(dú)立運(yùn)行，所有物流操作都直接依賴電商平臺(tái)的數(shù)據(jù)和流程。這意味著主平臺(tái)的任何變更都可能破壞系統(tǒng)的功能。
• 共享資料庫導(dǎo)致效能問題: 物流應(yīng)用程式和電商平臺(tái)使用相同的資料庫，這導(dǎo)致效能問題，尤其是在任一應(yīng)用程式的負(fù)載高峰期。此外，此配置使權(quán)限管理變得複雜，因?yàn)閷?duì)資料庫的任何存取都可能危及其他系統(tǒng)的重要資料。
• 無法獨(dú)立運(yùn)作: 該應(yīng)用程式的設(shè)計(jì)只能與電商平臺(tái)一起運(yùn)作。這不僅限制了其可移植性，還阻礙了在隔離環(huán)境中進(jìn)行測(cè)試或遷移到其他平臺(tái)。其依賴項(xiàng)沒有適當(dāng)?shù)姆庋b，任何隔離嘗試都需要對(duì)整個(gè)系統(tǒng)進(jìn)行大規(guī)模且代價(jià)高昂的更改，主要類別中沒有遵守單一責(zé)任原則（SRP）。
• 難以實(shí)現(xiàn)新功能: 缺乏對(duì)開放/封閉原則（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)。

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

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

• 與全球策略脫節(jié): 開發(fā)是孤立進(jìn)行的，沒有對(duì)公司內(nèi)部目標(biāo)和流程的完整了解。這導(dǎo)致了一些功能，儘管技術(shù)上是正確的，但並非總是符合業(yè)務(wù)的實(shí)際需求。
• 缺乏策略優(yōu)先事項(xiàng): 新功能的實(shí)施缺乏明確的評(píng)估和優(yōu)先排序流程。沒有質(zhì)疑一個(gè)功能是否真正必要，是否是最佳實(shí)現(xiàn)方式，或者是否有更有效的替代方案。
• 被動(dòng)式開發(fā) vs. 主動(dòng)式開發(fā): 開發(fā)主要遵循被動(dòng)模式，解決直接需求，而沒有考慮長(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)品越來越偏離實(shí)際需求
• 阻礙了與公司其他系統(tǒng)和流程的整合
• 讓關(guān)於產(chǎn)品的策略決策變得複雜
• 限制了團(tuán)隊(duì)的創(chuàng)新和持續(xù)改進(jìn)能力

基本成本的影響

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

在我們的案例中，基本成本包括所有因需要維護(hù)過時(shí)的框架和語言版本、解決因技術(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)部化開發(fā)的決定性因素，但在專案的初步診斷中，它具有相當(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)與策略決策

在任何重建項(xiàng)目中，都可以採(cǎi)用多種策略，並且經(jīng)常會(huì)遇到以下兩難：絞殺者模式（strangler fig）或徹底重寫（big bang rewrite）。

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

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

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

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

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

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

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

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

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