MISRA C 2012还有没有必要继续使用，MISRA规则版本发生切换时又会牵动哪些流程，对这个问题，不能简单地回答成“继续用”或是“马上换”。许多嵌入式工程已经按照MISRA C 2012开发了很多年，代码检查报告、偏离说明、客户评审资料以及供应商的交付要求，也都是围绕这个版本一层层建立起来的，如果团队一下子切到新版本，开发流程就会被重新拉动；可是如果团队一直停在旧版本上面，在新工程的评审、工具升级以及安全要求的补充中，也可能遇到麻烦。MISRA官方已经发布了MISRA C:2025，MISRA出版物页面也列出了与之相关的文档，因此团队现在讨论MISRA C 2012的时候，需要把历史工程和新工程分开来看。
一、MISRA C 2012还有必要继续使用吗
MISRA C 2012有没有必要继续用下去，要去看工程现在处在哪一个阶段，已经进入量产、维护、客户验收或者还在延续历史版本的工程，继续使用MISRA C 2012并不是一件奇怪的事。如果是新启动的工程，既没有客户指定版本，也不背历史包袱，团队就应该认真去评估后面的版本。
1、已经存在的老工程可以继续使用
许多产品已经按照MISRA C 2012把代码基线建立了起来，团队也完成了静态检查，并且处理过一批违规问题，客户评审资料里面同样写入了MISRA C 2012，如果这时候突然去切换版本，团队并不只是把代码重新扫描一遍，还得重新去解释旧问题和新问题之间的关系。
老工程继续使用MISRA C 2012，重点并不在版本是不是最新，而在于检查出来的结果是否稳定，偏离说明是不是写得完整，以后的修改是不是仍然照着原来的规则去执行，只要客户和内部流程都认可这个版本，团队就可以把它当成维护阶段的规则基础。
2、新工程要小心停留在旧版本上面
如果新工程还没有把流程正式冻结下来，团队就不适合直接把旧习惯搬过来用，MISRA规则的后续版本会补充对新的语言特性的支持，也会对一部分规则的表达和分类方式做出调整。要是团队仍然默认采用MISRA C 2012，等到后面客户问到版本选择的事情时，工程的负责人就需要去解释为什么不选用后面的版本。
新工程在挑选规则版本的时候，团队要去看客户的要求、工具的支持情况、编译器的版本、C语言标准的版本以及供应商代码的来源，假如团队只是因为过去一直这样做，就把MISRA C 2012继续写进计划里，这个理由是不够牢靠的。
3、客户指定了版本时就要照着客户的要求去做
有些工程会在合同、开发计划或者技术规范里面，把MISRA的版本写清楚，如果客户明确要求使用MISRA C 2012，团队就不能自己换成别的版本，要是客户要求用后续的版本，团队也不能只交一份MISRA C 2012的检查报告了事。
这一环节很容易生出问题，开发团队可能会觉得两套规则差别并不大，但评审人员看的是文件是不是前后一致，开发计划里写的是一个版本，工具报告显示的是另一个版本，偏离说明又按照旧版本去写，到了评审的时候就会被反复追问。
4、工具暂时不支持新版本时，可以分成阶段去处理
MISRA规则版本的切换不能只盯着标准本身，还要去看工具是不是支持，如果静态分析工具还不能完整地支持目标版本，团队硬要去切换，就会让人工判断的代价变高，报告导不出来，规则映射也不清楚，问题状态也不好去管理。
碰到这种情况，团队可以先保持MISRA C 2012作为正式的检查基线，再建一份新版本的差异清单，等到工具的支持稳定下来之后，再把新版本切进正式流程里，这样处理会更加平稳，不会把工程的节奏打乱。
二、MISRA规则版本切换会影响哪些流程
MISRA规则版本切换到底会影响哪些流程，团队不能只把眼睛盯在代码扫描上面，规则版本一旦发生变化，开发计划、工具配置、问题管理、供应商交付、客户评审这些环节全都会跟着起变化。如果团队没有提前把这些内容整理好，后面就很容易冒出报告能扫出来，但流程却对不上去的状况。
1、开发计划会受到影响
开发计划里面一般都会把编码规范、检查规则、工具名称和执行阶段写清楚，规则版本一切换，这些内容都需要同步去做更新，团队不能只去改动工具配置，却不去修改开发计划。
如果开发计划里还写着MISRA C 2012，而工具报告却按照新版本去输出，评审人员就会认为文件前后不一致，团队要提前把切换的原因、切换的时间、适用的模块以及例外处理的方式说明白，这样后面的评审才不会卡在版本的问题上面。
2、静态分析工具的配置会受到影响
静态分析工具通常都需要选定一套具体的规则集，当团队从MISRA C 2012切到后续版本之后，规则的编号、规则的分类、检查项的数量以及报告的格式，都有可能发生变化，就连旧工程里已经关闭掉的问题，也可能在新版本下面重新冒出来。
工具的配置不能由开发人员随手就去改动，团队需要把配置文件固定下来，把扫描命令写明确，把报告模板保存好，这样一来，不同的人员、不同的分支、不同的版本扫出来的结果，才方便放在一起做比较。
3、问题整改的清单会受到影响
版本切换之后，违规项的数量可能会发生变化，原来没有报出来的问题有可能会冒出来，原来已经处理过的问题也可能会被重新划分到别的类别里去，如果团队不去做区分，就会把真正新增的问题和版本切换带来的规则差异搅和在一起。
团队应当单独建立一份切换问题清单，在里面标清楚哪些问题是来自代码本身的，哪些是来自规则变化的，哪些需要去做修改，哪些可以用偏离说明保留下来，这样开发人员改起来心里就会清楚很多。
4、偏离说明也会受到影响
在嵌入式的工程里，偏离说明是经常要用到的，像寄存器访问、底层地址的访问、中断处理、启动代码、编译器扩展这些地方，可能没有办法完全躲开特殊的写法，规则版本一切换，原来的偏离说明就不一定还能直接拿去用了。
开发人员需要重新去检查一遍偏离说明，如果说明里面只写了旧的规则编号，那放到新报告里面就很难对应上，团队要把新旧规则的关系、保留的原因、影响的范围、测试怎样去覆盖，还有维护的责任都补进去，偏离说明不能只改一个编号就当作完事了。
三、MISRA C 2012切换前要怎么做
MISRA C 2012在切换之前先要做些什么，团队需要先把受到影响的范围内查清楚，版本切换并不只是把工具菜单动一动，也不是把文档里的版本号替换掉就算好了，团队应该先做一次小范围的验证，然后再去决定要不要全面切换。
1、先挑一个具有代表性的模块试着扫描
团队可以先挑一个代表模块做一次试扫，这个模块要能把常见的代码类型包含进来，像底层驱动、通信处理、控制逻辑还有和平台相关的代码，团队不要直接拿一段很小的样例代码去测，因为样例代码是看不出真实问题的。
试扫完成之后，团队要把旧版本和新版本的结果放到一起做比较，开发人员要去看新增的问题多不多，评审人员要去看这些问题是不是容易解释清楚，工程的负责人则要去看整改的时间能不能控制得住，这一步做好了，后面的切换就会稳当很多。
2、接着把新旧规则之间的差异整理出来
团队需要把新旧规则之间的差异一项一项地整理出来，哪些规则只是表达上有了变化，哪些规则把检查的要求给改了，哪些规则会影响到已经写好的代码，这些都要写明白，这个差异表不用做得太花哨，但要让开发、测试和评审人员都能看得懂。
等规则差异理清楚之后，团队就可以去判断哪些问题是需要立刻改掉的，哪些问题可以跟在版本计划的后面一步一步去处理，开发人员也不会一看到新报告就盲目地去改动代码。
3、要让文档和报告的口径保持一致
团队在决定切换版本以后，需要把文档和报告的口径统一起来，开发计划、编码规范、静态分析的配置、代码评审的记录、问题关闭的记录还有偏离说明，都要写成同一个版本才行。
这个动作不能一直拖到评审之前再去做，如果到了评审前才发现文档里面写的是MISRA C 2012，而报告上显示的却是新版本，团队就只好临时去补说明，临时拼凑出来的内容，通常很难讲得顺畅。
4、要给开发人员留出一段适应的时间
规则版本的切换会影响到开发人员的写法，如果团队直接就把新规则压到开发人员头上去，很多问题就会一下子集中地冒出来，开发人员会觉得规则一下子变多了，工程的进度也容易被拖累。
团队可以先安排一段过渡期，在过渡期里，先对新增的规则做出提示，然后再一步一步转成必须整改的要求，这样开发人员就有时间去理解规则，工程的负责人也能把控住整改的节奏。
5、在客户评审之前要提前做好说明
如果工程涉及到客户的评审，团队就要提前把MISRA版本切换的情况讲清楚，客户关心的不只是团队用了哪一个版本，他们也关心旧的问题怎么去处理，新的问题怎么去关闭，供应商的代码又怎么被纳入到同一套要求里面来。
团队可以在评审资料里面把切换的原因、切换的范围、工具的版本、差异的处理方式以及遗留问题的状态都写明白，这样客户看到报告的时候，就不会把版本的变化错当成代码质量突然变差了。
总结
MISRA C 2012还有没有必要继续使用，MISRA规则版本切换又会牵动哪些流程，这个问题要回到工程的阶段上去看，已经存在的工程、处在维护期的工程、客户已经指定了版本的工程，都可以继续使用MISRA C 2012，但团队要保证检查报告、偏离说明和后续的修改仍然能形成一个闭环。新工程要是没有历史包袱，就应该去评估后面发布的版本。MISRA规则版本切换会影响到开发计划、工具配置、问题整改、偏离说明、供应商交付和客户评审这些方面，团队需要先做试扫，再整理差异，接着把文档和报告口径统一起来，这样一来，切换才不会变成临时去改一个版本号，也不会在评审的时候留下讲不清楚的问题。
