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