大多数嵌入式软件开发团队在某个阶段都需要使用遗留代码，无论是出于成本考量，还是因为相比迁移到新代码库，复用现有代码更为便捷。问题在于，遗留代码的具体功能可能并不明确，这需要投入精力去理解，并编写新的测试用例来验证其是否仍能按预期运行。即使背景信息和测试用例仍然存在，遗留代码也可能不符合当前的编码规范，或无法满足功能安全及安全标准的要求。
遗留代码通常难以集成到其他系统、适配新数据格式或部署到现代平台及云端托管环境。相关代码可能已不再提供安全更新和补丁，供应商或开源社区的支持也可能逐渐减少甚至消失。然而，如果使用遗留代码不可避免，以下是一些最佳实践建议：
1. 测试代码
创建特征测试（Characterization Tests）和单元测试，并使用静态代码分析器等代码质量工具，以理解代码功能并揭示其在功能、性能、安全性和编码标准合规性方面的问题。
2. 审查文档
检查原始需求和功能说明，了解代码的来源及其当前运行机制，识别可能不符合新用途的缺失部分。
3. 仅重写必要代码
尽管重写整个遗留代码库看似诱人，但此举风险极高：既耗费时间，又可能因知识不完整而引入缺陷或依赖性问题。更好的策略是选择性重写。
4. 重构遗留代码
更务实的方案是逐步重构——在不影响代码功能或外部行为的前提下调整其结构。重构还能生成更“整洁”的代码，易于理解维护且更少出错。
5. 分阶段实施变更
避免一次性过多修改，否则管理、测试和修复的复杂度会不必要地增加。通过限制变更范围，评审者能更清晰地审查改动，而非淹没在大量变更中。
6. 开发者协作
即使并非所有团队成员都熟悉特定遗留代码，也应鼓励团队协作。这有助于共享代码库知识，同时减少时间和精力消耗，且“第二双眼睛”的审查总是有益的。
7. 保持新代码规范
例如遵循企业编码最佳实践，并符合适用的编码标准。
8. 谨慎尝试AI工具
为加速流程可考虑AI技术，但需保持警惕。AI能快速重写遗留代码，但其输出可能因训练数据和自身理解能力引入功能变化。不过，AI技术（如大语言模型LLM）正在持续改进，值得在结合人工解读和专业经验的前提下进行实验。
9. 借助权威资源
可参考Michael C. Feathers和Martin Fowler等专家关于遗留代码和重构技术的著作。
未来维护建议
为避免遗留代码的长期维护问题，在编写或更新代码时：
- 采用广泛认可的编码标准
- 编写充分注释和文档化的代码
- 使用版本控制系统管理和追踪代码变更
- 实施自动化持续测试，确保代码随时间推移仍保持功能性与可靠性
- 关键是通过安全编码技术、安全测试及静态分析工具（如Perforce的Helix QAC和Klocwork），遵循代码安全最佳实践，最大限度降低软件生命周期内的安全风险。
总结
对许多嵌入式团队而言，遗留代码的复用不可避免。但通过采用经过验证的技术和工具，混合新旧代码的现代嵌入式项目仍能满足安全与安规标准的要求。
