怎样安排MISRA培训才会更有效果，以及团队在落地时常遇到的阻力该怎么去化解，这个问题不能只是被理解成给开发人员上一堂规则课。很多项目组在做MISRA培训的时候，会讲上一大堆规则编号，也讲了很多专门的概念，可开发人员回到工程里面，还是不清楚该怎么去改代码，也不清楚哪些问题是必须处理的，更不清楚例外的说明要怎样去写，要让MISRA真正落到工程里面，培训就要把代码、工具、问题单还有评审资料放在一起讲，项目组也要提前把阻力化解掉，像开发人员会感觉规则拖慢了进度，工程负责人会觉得流程变重了，供应商会觉得要求不够清晰，如果培训安排得明白，落地时遇到的阻力也处理得及时，MISRA才不会一直停留在工具报告和文档要求里面。
一、怎样安排MISRA培训才会更有效果
想让MISRA培训起到作用，项目组就不能只照着规则的章节从头讲到尾，开发人员把规则听完以后，终究还是要回到真实的代码里面去干活，所以培训的内容要和工程的现场连在一块，项目组要让开发人员明白规则为什么提出这样的要求，问题会出现在哪些地方，代码应该怎样去修改，当不能修改的时候，又应该怎样去写说明。
1、培训的对象要先分出层次
MISRA培训不能叫所有人都去听同一套东西，开发人员需要听的是规则的含义、常见的违规写法、修改的办法还有工具的操作方法，测试人员需要听的是问题怎么复测、报告怎么确认还有关闭的记录，工程负责人需要听的是规则的范围、问题的统计、偏离的审批和评审的准备，质量人员则需要听流程的记录、问题单的字段和证据的保存。只要项目组把对象分清楚了，培训的内容就不会搅成一锅粥，开发人员不用去听太多管理上的口径，工程负责人也用不着去深挖每一条代码的写法，每一类人员只听自己真正用得上的那一部分，培训的效果就会更明显。
2、培训的内容要围着真实的代码来展开
如果MISRA培训只去讲规则的原文，开发人员很快就会感到枯燥，项目组更合适的办法，是把工程里的真实代码拿出来当例子，类型转换是怎么出毛病的，宏定义为什么不容易检查，指针的边界又为什么要交代清楚，这些内容全都要结合着代码片段来讲。真实的代码能让开发人员更容易把规则吃透，当他们看见自己平常的写法被工具报了警，就会知道问题并不是抽象的规定，而是工程里面确实存在的风险，培训不用讲得太花哨，把代码的例子讲明白，要比单纯去解释规则的编号更有用处。
3、工具的操作要和规则的讲解串在一起
MISRA培训不能光讲概念，也不能光讲工具的按钮，项目组需要把规则的讲解和工具的操作放到一块，开发人员要明白工具为什么会报出这条问题，也要清楚报告里面有哪些信息是重点要看的。项目组可以安排一回完整的演示，让开发人员先看一小段代码，再用工具去扫描，接着查看报告，然后修改代码，最后再复扫一遍来做确认，这个过程走通以后，开发人员就会知道，MISRA检查并不是到了快交付的时候才去做的事情，而是平时开发里的一部分。
4、问题单的写法要单独拿出来训练
很多项目组在MISRA上的问题，并不是卡在代码的修改上，而是卡在问题单的关闭上，开发人员常常只写上“已修改”“误报”“工程需要”这几句，这些话在内部沟通的时候也许勉强能看明白，但到了客户评审的时候，就很难撑得住结论。所以培训的时候，要专门去讲问题单的写法，用修改来关闭的，要写清楚改了什么位置，复扫是不是通过了；用误报来关闭的，要写明工具为什么报了错，而代码实际上又没有违反规则；用偏离来关闭的，要写明保留的原因、影响的范围、隔离的办法、测试是怎么去覆盖的，还有维护的责任，开发人员把这些写法练熟之后，后面的评审就会省掉很多事。
二、MISRA团队落地常见阻力该怎么去化解
在谈MISRA团队落地时常见的阻力怎么化解之前，项目组先要承认这些阻力都是正常的，开发人员会担心工作量变大了，工程负责人会担心进度受到影响，供应商则会担心交付的要求变得越来越复杂，这些反应都相当普遍，项目组不能光用一句“这是标准的要求”就把事情压下去，而是要把规则能带来的好处和执行的边界都讲明白。
1、开发人员觉得规则拖慢了进度
开发人员常常会觉得MISRA问题数量太多，改起来很费功夫，这种阻力是非常真实的，假如项目组把所有问题一次性全都压到开发人员头上，开发人员就很容易产生抵触。工程负责人可以先把问题分出级别，那些对稳定性、内存安全、边界处理还有接口数据有影响的问题，要优先去处理；而格式类、老代码类、低风险类别的问题，可以按着计划分批次来处理，项目组把整改的节奏拆开以后，开发人员就不会被一大堆问题给压垮了。
2、开发人员觉得规则太死板
有一些嵌入式代码确实很难完全绕开特殊的写法，像寄存器访问、底层地址的访问、中断处理、编译器的扩展这些地方，常常会碰到MISRA的规则，开发人员要是觉得规则不能理解底层开发的工作，就很容易直接把MISRA当成了负担。项目组要提前把偏离的机制讲清楚，MISRA并不是要求所有的代码都去机械地修改，如果某段代码真的需要把特殊的写法保留下来，开发人员就可以走偏离说明的路子，项目组要看的是理由是不是足够充分，影响的范围是不是清楚，测试有没有覆盖到，而不是叫开发人员为了把报警消掉，反而把底层的代码给改坏了。
3、工程负责人觉得流程变重了
工程负责人会担心MISRA落地以后，会议、文档还有审批全部都要变多，这种担心也是有道理的，如果项目组把流程设计得过于复杂，MISRA就会变成一份额外的负担。流程设计要尽量简单，项目组只需要把关键的证据留下来，比如工具的配置、扫描的报告、问题单、复扫的记录还有偏离的说明，问题单的字段要固定住，审批的角色要明确下来，报告的存放位置也要统一，流程越是清楚，工程负责人就越是容易把握住进度。
4、供应商觉得要求讲得不清楚
很多工程都会用到供应商的代码，供应商要是不知道用哪一个MISRA版本，不清楚报告要交什么东西，也不知道偏离说明该怎么写，到了后面做集成的时候，就会出现口径对不上的状况。项目组需要把给到供应商的要求写清楚，在交付说明里要写明规则的版本、工具的要求、扫描的范围、未关闭问题的处理方式还有偏离说明的格式，供应商在提交代码的时候，也要把对应的检查报告一并交上来，主工程的团队还要对供应商的问题做一次复核，不能光看供应商说自己已经处理过了。
三、MISRA培训的效果要怎么持续去跟踪
MISRA培训结束之后，项目组还要去跟踪它的效果，培训当天听懂了，并不代表在工程里就能执行好，项目组要去看开发人员是不是真的会去改问题，问题单是不是写得清楚，工具的报告能不能和代码的版本对应上，偏离的说明又能不能经受住评审的考验。
1、项目组要去看问题数量上的变化
项目组可以定期去查看MISRA问题的数量变化，新增代码里的问题数量是不是降下来了，同一类问题是不是还在反复出现，重点的模块里面是不是还堆着大量没有关闭的问题，这些数据都能把培训的效果反映出来。看数据的时候不能只盯着总数，项目组还要去看问题的类型，比如类型转换的问题反复冒出来，就说明开发人员对数据范围的理解还不够；宏定义的问题反复出现，就说明项目组可能还需要再补一份关于宏的使用规则，数据看得细一点，后续的培训就能更有针对性。
2、项目组要抽查问题单的质量
项目组可以每周都抽一部分问题单来看一看，对于用修改来关闭的记录，要去看复扫的结果；对于用误报来关闭的记录，要去看判断的根据；对于用偏离来关闭的记录，要去看保留的原因以及测试有没有覆盖到。抽查不用搞得很重，工程负责人和质量人员只要固定地看上个几条，就能找出不少问题，如果问题单的质量长时间都不去查，到了后面评审的时候，问题就会集中地暴露出来。
3、项目组要沉淀出一套常见问题库
项目组在执行MISRA的过程中，会反复碰到一些相似的问题，像指针转换、宏的副作用、数组的边界、整数的范围、未使用的返回值等等，这些问题都可以整理成一套常见的问题库。常见问题库要写得简单一些，每一条问题里就说明一种违规的写法，再给出一小段推荐的写法，然后补上一句注意点，这样开发人员再碰到差不多的问题时，就可以直接拿来参考，新员工做培训的时候，也能靠着这些材料更快地进到工程的状态里面。
总结
怎样安排MISRA培训才会更有效果，还有MISRA团队落地时常见的阻力该怎么去化解，项目组要把培训和工程的执行放到一起来看，培训的对象要分出层次，培训的内容要结合真实的代码，工具的操作和问题单的写法也要交代清楚。团队在落地的时候，开发的进度、偏离的机制、流程的负担、供应商的交付还有各个角色的责任，这些都会带来阻力，工程负责人要把问题分好级别去处理，把证据记录做清楚，把给到供应商的要求提前写明白。MISRA培训并不是把规则讲完就结束了，项目组还要持续去跟踪问题的数量、问题单的质量、常见问题库，还有工程复盘的结果，只有这样，MISRA才能真正进到日常的开发里面，而不是只停留在培训的材料当中。
