芯耀
283
我是老温，一名热爱学习的嵌入式工程师
关注我，一起变得更加优秀！
很多嵌入式工程师在接手别人的代码的时候，通常都会面临一种困惑局面：以前的代码结构混乱，维护难度高，想进行代码重构，却经常被公司的资深老鸟劝阻。
其实，并不是不让重构，而是嵌入式软件相较于PC或移动端软件，其对硬件适配性和稳定性的要求更高，嵌入式软件代码重构，是一个需要慎重考虑的过程。
搞嵌入式开发的都知道，嵌入式软件通常与硬件外设深度绑定且高度适配，二者的关联性极强，重构的过程如果出现适配偏差，轻则导致运行异常，重则系统宕机，设备变砖。
在考虑进行嵌入式软件代码重构之前，需要充分考虑以下三点：
一、重构易破坏代码与硬件的适配关系。
在嵌入式代码里面，有时候有些看似冗余的代码片段，实际上可能是适配硬件特性的关键逻辑，重构的时候如果误删或者修改此类代码，可能会导致硬件无法正常运行。
比如，某直流电机控制，有一行表面上看似无关重要的延时代码，它的作用是为电机启动提供0.5秒的缓冲时间，避免电机因为瞬时冲击电流而损坏，这一行代码是保障硬件正常运行的重要逻辑。
但是，如果工程师在重构时误判该代码无用并将其删除，或者更改了延时的机制，则有可能会导致电机启动异常，或者导致机械结构损坏。
二、代码的稳定性，远高于规范性和美观度
工程师重构嵌入式软件代码的初衷，基本上都是为了改善旧代码混乱、命名不规范、结构不清晰的问题，从而提升代码的可读性和可维护性。
但是，嵌入式软件的核心关键是长期稳定运行，有时候即使代码结构不够简洁，命名不够规范（俗称：屎山代码），但设备依然能够正常稳定工作，这份代码即为“合格代码”。
比如，以某款很老旧的工业控制器为例，原来的工程师在开始设计的时候使用了大量的全局变量，某工程师对全局变量进行优化，并且“自以为是”地改进了代码结构，
结果，在测试的时候发现，控制器频繁丢失数据，控制指令延迟执行等问题，经排查得知，全局变量虽然不符合代码规范，但能够让数据同步得到快速响应，所以，真的别随便优化已经稳定运行多年的代码！
（这里并不是提倡大量使用全局变量，原因在这：实习生写的嵌入式代码，滥用全局变量，被我狠批了一顿！）
三、重构极易引入故障，某些场景排查难度非常高
嵌入式软件的运行环境非常复杂，有时候需要应对高低温和强电磁干扰等极端工况，很多故障在实验室环境里面难以显现出来，仅仅在特定工况下才会逐一暴露。
在重构过程中，有时候即便是微小的修改，如变量类型的调整、代码执行顺序变更等等，都有可能埋下故障隐患，给系统稳定运行带来风险。
比如，某工程师把一个原来是32位的整型变量改为16位的，他认为当前数据范围无需用到16位，这样可以节省一些系统内存，并且在实验室阶段，设备测试运行一切正常。
然而，在实际的设备工况环境下，由于数据的刷新频率比实验室环境高得多，从而经常出现变量溢出的问题，导致设备偶发黑屏故障，这个故障排查了一周，费时费力。
四、测试周期长，测试成本高
嵌入式软件的测试环节也是软件重构需要慎重考虑的重要原因，普通的APP重构之后，可以对核心功能进行快速测试验证，后续如果出现问题可以进行快速迭代修复，测试成本相对较低。
但嵌入式软件经过重构之后，需要进行全流程测试，包括单个模块测试、模块整合测试、整个系统测试，同时还需要模拟各类极端工况和长期稳定性测试，部分测试周期可达数周甚至数月。
如果重构之后发现故障，还需要重新修改代码并重新开展全流程测试，大幅增加人力和时间成本。
需要明确的是，嵌入式软件并不是不可以重构，当旧代码维护难度极高、故障频发，或者旧的代码架构已经无法适配新的业务需求的时候，代码重构就是必要的优化手段了。
但重构的过程需要循序渐进，并且需要安排必要的评审环节和测试环节，切忌盲目地为了代码的规范性而进行大面积的代码修改，也就是，能稳定运行的“屎山代码”，不要随便修改！
以下几点，是嵌入式软件代码重构的关键步骤，希望能帮助各位老铁降低踩坑的概率：
1、明确原有代码与硬件之间的适配逻辑，记录关键的硬件适配功能，避免误删误改。
2、对原有的源代码，编译环境，测试环境，进行完整备份，以便于发生故障时能迅速回滚。
3、划分模块，划分阶段，小幅度推进模块重构，单个模块重构完成后即可进行布局测试。
4、依次完成局部模块测试、系统整合测试、系统功能测试、可靠性测试，重点验证极端工况下的长期运行稳定性。
5、总结重构过程中的经验，完善代码注释，编写软件相关的文档并进行评审保存，提升后续的可维护性。
总而言之，嵌入式软件重构，就好像为之前稳定运行的设备更换零部件，不能直接停机硬拆硬换，而是需要小心翼翼循序渐进地更换，同时需要全程监控设备的运行情况。
对于嵌入式软件而言，稳定运行是其核心前提，需要遵循科学的重构步骤才能充分发挥代码重构的核心价值，这也是资深的老鸟工程师反复强调“重构嵌入式代码需慎重”的主要原因！
-END-
