MISRA偏离流程总被卡住是什么原因MISRA偏离审批最容易缺少哪些依据，很多情况下，问题倒不是出在代码那一头当真就一点不能偏，而是交上去的偏离申请，没能把“为什么非得偏开这一条、偏开以后会冒出哪些险处、这些险处又打算靠什么来按住、最后该由谁来做这个主”给交代得明明白白。在MISRA Compliance:2020里面，对于deviation record和deviation permit这两样东西，是专门有分开来说的，偏离许可能给偏离记录凑上不少材料，可这俩东西是不能随随便便就搅和到一堆去看的。

　　一、MISRA偏离流程总被卡住是什么原因

　　MISRA偏离这件事，它本来的打算倒不是让人去给那些告警硬找一个说头，而是想着在碰见那些很特别的情况时，能保留下一个说得清、审得了、往后也追得到根子的工程上的判断。流程会卡在那走不动，常常是因为收上来的那堆材料，光讲了“这个地方把规则给碰了”，却没往下说清“为什么偏就不能去动它”。

　　1、偏离理由太泛

　　不少偏离申请，在上面只写了类似“历史代码原因”“平台限制”“修改影响较大”这么几句话，这些理由猛一看过去好像挺在理的，可就是缺了能让审批的人拿去往下做决断的实在东西。审批的人真正想看到的，是那个限制的根子到底是从哪儿冒出来的，是因为编译器的行为拗不过来，还是第三方的库接口硬是把路给挡住了，是硬件那头的寄存器访问绕不开，还是跑起来性能上的要求就被卡在那儿了，再不然就是因为已经有了的接口兼容的事情没法动。要是原因落不到这些具体的点上，审批就很难再往前推得动。

　　2、规则影响范围不清

　　在【偏离记录】中写清规则编号、代码位置、触发原因和影响模块。

　　同样一条MISRA的规则，放在不一样的地方，它可能带出来的险处是完全不同的。一条搁在普通工具函数里头的偏离，跟一条塞在和安全拴得很紧的控制路径里头的偏离，这两样在审批时候的严格劲儿，肯定不是一回事。要是申请里头没有把影响的块块给说明白，评审的人就弄不清这次偏离是只窝在原地的一个小麻烦，还是已经偷偷摸摸地散到了好几个模块里面去。

　　3、替代措施没有说明

　　有些申请，它光是证明了“眼下这份代码暂时是动不得的”，却不接着往下去讲一句“既然不动它，后面又要拿什么样的法子去管住这个险处”。就比如说，为了去够那个硬件的寄存器，代码里头不得不做一回类型转换，那么这个时候，就得把访问的那个地址是不是定死了的、外头有没有给套上一层封起来的接口、调用它的那个范围是被圈起来了还是放得很开、代码有没有被人仔仔细细审过，还有测试到底有没有盖住这些地方，一样一样地给讲出来。少了这些替代的招数，偏离瞧上去就会像是单方面地绕着规则给溜走了。

　　二、MISRA偏离审批最容易缺少哪些依据

　　做偏离审批，最叫人头疼的就是那些材料零的零散的散，压根凑不到一块儿去。开发那头心里知道为什么写成这么个样子，测试那边呢，大概也晓得功能上头没闹出过毛病，可一落到纸上，这些信息全没有被串起来，等到了评审的场合里头，光靠着嘴皮子去解释，这么一来，申请是顶容易就被打回来的。

　　1、缺少代码上下文

　　审批的那会儿，可不是光把工具跳出来的告警截个图往上一递就能过去的，得让看的人还能见着文件名叫什么、函数的名儿是什么、一小段实打实的代码，还有触碰到这条规则的那个准确地方。把这些代码的上下前前后后都给摊开来，评审的人才能去断一断，这段代码到底是在跑着一般般的逻辑，还是说脚已经踩进了指针的摆弄、类型的强转、位操作、宏那一套定义、硬件寄存器这些水深的地方里头去了。

　　2、缺少风险分析

　　在风险分析那一块，光抛出去一句“这里险处是低的”是指望不上的，得把那些可能被惹出来的麻烦一样一样给摊清楚了，就像会不会闹出来那种没给定义过的行为、有没有越到不该去的地方去访问、类型会不会半道上被截断了、以后别人看的时候会不会被带歪，又或者测试上头有没有漏掉的口子。接着呢，再去解释这些险处凭什么就能被按住，比如讲，输进去的范围是被卡死了的，调用的路线就单单那么一条，地址是被圈在很小的范围里头的，边界上早就给挡着了，再不然就是那些相关的岔路，全都已经掉进了单元测试的大网里，都被跑过了。

　　3、缺少验证证据

　　把【静态分析结果】、【单元测试记录】和【代码评审记录】补到偏离结论后面。

　　偏离审批，它可不是光把那几条理由死盯着看就算完的，一样要找验证上头的东西。特别是在碰到了那种跟指针的搞法、硬掰过去的类型转换、宏的那套定义、对硬件一脚一脚的直接敲打，还有那些拐来拐去的条件判别的时候，最好能把测试跑出来的结果，又或者评审那时候留下来的字据给补到后头去。光搬出来一堆说头，却不把验证的那一摞东西摆到台面上，这个结论就容易叫人觉着底下不怎么瓷实。

　　三、MISRA偏离流程怎么更顺畅地推进

　　要把偏离的流程给推得顺溜些，就不能老把事情一直拖到项目的尾巴尖上，才去一次性去清那一堆告警，越挨到后面，代码就越发不敢大动，改一改的代价也跟着往上直蹿，偏离的申请还更容易一窝蜂地堆成小山，审起来自然就快不了。

　　1、先判断能不能改

　　不是所有MISRA告警都非被拽进偏离这条道里来不可，那些能靠着把代码的架子整一整、把类型给扳正了、或者在面子上套一层接口就收拾干净的问题，还是先紧着去动代码这一头比较好。只有到了改它一下就会把功能给捅漏、会牵动到对硬件的那一层碰触、说不定引出更大的纰漏，又或者是被第三方的代码死死地卡在那里动不了的时候，才更该去走偏离的那趟流转。

　　2、统一偏离模板

　　偏离的那个模子，它最起码得把这么几样东西给装进去：规则是哪一个号、代码杵在什么位置、为啥偏要撇开这一条、险处是要怎么去掰开来瞅的、用上了哪些替代的把式去兜底、验证跑没跑、这一条偏能用多大的范围、谁拍了板，还有后面再翻出来查一查的条件。模子一旦给固定死了，搞开发的就犯不着每一回都去重新攒材料了，审材料的人呢，也能照着同一把尺子去断，再不会闹到一个项目一个说道，来来回回地在那掰扯。

　　3、定期复查历史偏离

　　前头攒下来的那一摞偏离，不能批完了就往那犄角里一丢，再也不去翻它。工具版本往上蹿了一级、底下的平台从这头被挪到了那头、代码又被倒腾着重构了一遍，这些一动，原先那些不得不偏开的问题，指不定现在已经能老老实实地给修掉了。隔上一阵子就复查上一遍，一来能把那些剩下来的偏离往下减一减，二来也不会让同一种类的问题一堆一堆地攒在那里老不去收拾。

　　总结

　　MISRA偏离流程总被卡住是什么原因MISRA偏离审批最容易缺少哪些依据，归了包堆，根子上的毛病，常常倒还不是“准不准偏开”，而在于交上去的那堆材料，到底有没有把偏开它的由头、窝在里头的险处，还有拿去勒住它们的法子，一样一样给讲得透透的。在流转上，得躲着那些道理说得太飘、路径划得很糊、验证也跟不上的坑；在证据上呢，又得把代码的上下前后、风险的扒拉、替代的招数、测试跑出来的印子，还有白纸黑字的拍板记档，全都给补齐了。这么弄下来，那一条偏离才不算是随随便便就被漏过去了，而是一桩站得住脚、也能倒回去翻查的工程上的盘算。