大多數(shù)嵌入式軟件開發(fā)團隊在某個階段都需要使用遺留代碼，無論是出于成本考量，還是因為相比遷移到新代碼庫，復(fù)用現(xiàn)有代碼更為便捷。問題在于，遺留代碼的具體功能可能并不明確，這需要投入精力去理解，并編寫新的測試用例來驗證其是否仍能按預(yù)期運行。即使背景信息和測試用例仍然存在，遺留代碼也可能不符合當前的編碼規(guī)范，或無法滿足功能安全及安全標準的要求。

遺留代碼通常難以集成到其他系統(tǒng)、適配新數(shù)據(jù)格式或部署到現(xiàn)代平臺及云端托管環(huán)境。相關(guān)代碼可能已不再提供安全更新和補丁，供應(yīng)商或開源社區(qū)的支持也可能逐漸減少甚至消失。然而，如果使用遺留代碼不可避免，以下是一些最佳實踐建議：

1.測試代碼

創(chuàng)建特征測試（Characterization Tests）和單元測試，并使用靜態(tài)代碼分析器等代碼質(zhì)量工具，以理解代碼功能并揭示其在功能、性能、安全性和編碼標準合規(guī)性方面的問題。

2.審查文檔

檢查原始需求和功能說明，了解代碼的來源及其當前運行機制，識別可能不符合新用途的缺失部分。

3.僅重寫必要代碼

盡管重寫整個遺留代碼庫看似誘人，但此舉風(fēng)險極高：既耗費時間，又可能因知識不完整而引入缺陷或依賴性問題。更好的策略是選擇性重寫。

4.重構(gòu)遺留代碼

更務(wù)實的方案是逐步重構(gòu)——在不影響代碼功能或外部行為的前提下調(diào)整其結(jié)構(gòu)。重構(gòu)還能生成更“整潔”的代碼，易于理解維護且更少出錯。

5.分階段實施變更

避免一次性過多修改，否則管理、測試和修復(fù)的復(fù)雜度會不必要地增加。通過限制變更范圍，評審者能更清晰地審查改動，而非淹沒在大量變更中。

6.開發(fā)者協(xié)作

即使并非所有團隊成員都熟悉特定遺留代碼，也應(yīng)鼓勵團隊協(xié)作。這有助于共享代碼庫知識，同時減少時間和精力消耗，且“第二雙眼睛”的審查總是有益的。

7.保持新代碼規(guī)范

例如遵循企業(yè)編碼最佳實踐，并符合適用的編碼標準。

8.謹慎嘗試AI工具

為加速流程可考慮AI技術(shù)，但需保持警惕。AI能快速重寫遺留代碼，但其輸出可能因訓(xùn)練數(shù)據(jù)和自身理解能力引入功能變化。不過，AI技術(shù)（如大語言模型LLM）正在持續(xù)改進，值得在結(jié)合人工解讀和專業(yè)經(jīng)驗的前提下進行實驗。

9.借助權(quán)威資源

可參考Michael C. Feathers和Martin Fowler等專家關(guān)于遺留代碼和重構(gòu)技術(shù)的著作。

未來維護建議

為避免遺留代碼的長期維護問題，在編寫或更新代碼時：

• 采用廣泛認可的編碼標準
• 編寫充分注釋和文檔化的代碼
• 使用版本控制系統(tǒng)管理和追蹤代碼變更
• 實施自動化持續(xù)測試，確保代碼隨時間推移仍保持功能性與可靠性
• 關(guān)鍵是通過安全編碼技術(shù)、安全測試及靜態(tài)分析工具（如Perforce的Helix QAC和Klocwork），遵循代碼安全最佳實踐，最大限度降低軟件生命周期內(nèi)的安全風(fēng)險。

總結(jié)

對許多嵌入式團隊而言，遺留代碼的復(fù)用不可避免。但通過采用經(jīng)過驗證的技術(shù)和工具，混合新舊代碼的現(xiàn)代嵌入式項目仍能滿足安全與安規(guī)標準的要求。