在把MISRA检查接到CI里面之后，噪声太大的问题该怎么处理，门禁阈值在分阶段收紧的时候又该怎样去设置，这些其实是很多嵌入式项目在往前推代码规范的过程中都会碰到的事情。刚把CI接进来那阵子，告警多这件事倒并不奇怪，特别是当历史代码、第三方的库、机器自动生出来的代码，还有平台适配的代码全被一把头扫进去的时候，CI是很容易每一次都挂上红的。在这个阶段里头，不能一上来就催着要把所有的东西都给清到零，可也不能就那么两手一摊什么都不去管了。比较讲得过去的搞法，是头一步先把那一片噪声给拨拉开了，再跟着去把基线楔下去，最末了再分着阶段把门禁给朝紧里勒一勒。

　　一、MISRA检查接入CI后噪声太大怎么办

　　MISRA告警的噪声会变得很大，在不少时候，倒不是因为代码一下子就变糟糕了，而是扫描的范围、规则的配置，还有历史堆下来的那些问题没有被拆开来看，所以只要先把问题分成一层一层的，后头再去动手整改的时候才不容易乱掉。

　　1、先收敛检查范围

　　在【CI配置】中先区分新开发代码、历史代码、第三方代码、自动生成代码和平台相关代码。

　　自己项目里动手写出来的那部分代码，是可以被放进主门禁里去的，而像第三方的库跟自动生出来的那些代码呢，就把它单拎到一边去扫描、去归档，到了实在躲不开的时候再走偏差说明的路子。这样来做倒不是说要把规矩往回抽一抽，而是怕CI反过来被那些项目管不住的代码给埋住了，结果弄得真正该去修的地儿反倒模模糊糊瞧不真了。

　　2、建立初始基线

　　刚刚把东西接进去的那一阵子，应该先给整出来一份【基线报告】，把眼下正使着的工具是哪个版本、规则那一块是怎么设的，还有已经躺在那里头的告警条数全给记下来。

　　基线它的用处倒不是去认下所有的这些毛病都是应当应分的，而是先把历史上堆下来的那码事给暂时冻在那儿，往后的CI里头呢，就可以先管住“新蹦出来的告警不准往主干里头合”，而不是撵着人一口气把那些老问题全给磕干净，这样做下来，门禁才算是留出了一块能往下推的空当，搞开发的那一批人也才会更加容易接得住。

　　3、区分告警类型

　　扫出来的告警得把它们拨拉成几堆，有一堆是不修不行的，有一堆是可以许它走偏的，有一堆是能往后头缓一缓再动的，还有一堆则是叫工具给认岔了的误报。就打比方说那种没给定义好的行为、悬乎乎的类型转换、数组有越界的险处、空指针的麻烦这些，就该给摆到前头去先料理；至于那些跟名儿叫法挂钩的事、注释里头的茬子，还有一部分搭着风格边的小毛病呢，是可以顺着版本往前拱的步子，一茬一茬地拾掇干净的。归了包堆，只要分类分得越是清爽，CI里头的那些个噪声，也就越发容易变成一份能攥在手上打理的清单了。

　　二、MISRA门禁阈值分阶段收紧时该怎么设

　　门禁的那道阈值，是没办法一上来就给它卡得太死的，要是卡得太死呢，团队这一头十有八九就会去绕着规矩转；可要是老那么只蹦出几句提醒的泡泡，却从来不去正身拦一道呢，检查这桩事也就拿不住那股子能叫人服帖的劲头了。所以把步子拆开来，一截一截地往前拱，叫大家伙先慢慢顺过来，再一回一回地把要求往高了拔，这样的搞法才更加把稳。

　　1、第一阶段只拦新增告警

　　刚刚才把东西接进去的当口，可以在【门禁规则】里头定下这么一条，就是新多出来的MISRA告警不准它合到主干里头去，至于那些还窝在历史基线里头的旧问题呢，就暂时先不去掐断构建的流程，这个阶段瞄的靶子就是先把血给止住，甭叫问题再接着往上面摞，搞开发的人他只用去料理自个儿交上去的那份代码里带进来的新告警，也就不会被背上那堆老包袱给生生拖在原地了。

　　2、第二阶段按风险等级收紧

　　等到新告警那一边差不多已经稳下来以后，就能抢在前头去把那些硬性规定的条款、风险冒得高的规矩，再有就是项目里头白纸黑字交代过不许去碰的规则，优先给拦下来。就比方说在控制流的上面、类型安不安全的上面、内存到底是怎么个访问法的上头，还有指针使起来的招数这些地方，是可以叫它们早一脚就掉进那种强门禁的池子里去的；至于那些偏风格的东西，还有风险不怎么高的建议呢，倒是可以继续叫它往外蹦着提示，后头再慢慢地一把一把给勒紧也不迟。

　　3、第三阶段推动存量下降

　　那些在历史上堆了下来的告警，是老没办法赖在基线里一丁点儿都不动的，可以照着版本的步子去定一个往下降的靶子，就比方说每跑完一茬迭代就给它关掉那么一坨，再不济呢，就把那些跟安全拴在一块儿的模块、隔三差五就被翻出来修修改改的模块、还有眼瞅着就要往外头交货的模块，搁在前头去清理。到了这个份儿上，可不能单把一双眼盯在总的数目是不是往下掉了，更得去瞧一瞧那些风险冒得高的告警到底有没有真真地少下去。

　　三、MISRA门禁落地时要注意什么

　　把MISRA的门禁往地上落的时候，得留心几样事，门禁这个东西它心里头瞄的可不是叫CI一天到晚地只把红灯给挂出来，而是要叫代码里头的那些险处能更早地露头。所以说，规矩里头定下来的那些个例外、该谁去扛这件事、还有把问题给关掉的凭据，全都得理个清清爽爽的，要不然的话，这个门禁是很容易就滑成了一场走走过场的查看的。

　　1、偏差不能随便放行

　　对那些实在是没法子去动手改的底层的代码、硬件的寄存器访问、编译器自己扩出来的那套东西，倒是可以通过【偏差记录】去把触到的是哪条规矩、代码窝在哪个旮旯、偏开去的原因、藏在底下的风险，还有拿去验它的方式一样一样给说明白。但是搁在那些业务代码里头，能动手去修掉的问题，就不大再主张长年累月地靠着偏差这一条道给放过去了，要不然的话，偏差管理这一整套东西，早晚会变成一条绕着门禁偷偷朝外溜的缝子。

　　2、工具配置要保持稳定

　　在CI里头跑着的那个工具的版本、编译时候甩过去的那些参量、那一整套规则集，还有被划到外头去的排除面，全都是要给死死固定下来的。要是这配置三天两头地在那变来变去，那告警的条数也就会跟在后头一摇一晃的，团队这头可就弄不灵清了，到底是代码在这头起起落落地变呢，还是工具那一边在暗地里头动着手脚。等到规矩往上拔了版本的时候，也一样要重新给生出来一份基线，可不能把新旧两样扫描出来的东西就那么直筒筒地搅到一堆去。

　　3、关闭问题要配合回归

　　去关掉一个MISRA上的问题，可不能光去盯着那个告警的印子消没消，还得去翻一翻动了那一下子有没有把旁的功能给牵着走。特别是跟指针、宏的那一套、类型的转换、边界的判法搭上界的这类代码，在动过手以后，是要把单元测试或者回归测试给配上，去好好确准一下的，免得光为了去扫掉一个告警，倒把新的毛病给悄没声地埋在了脚底。

　　总结

　　归了包堆来看，MISRA检查在挂到CI上去以后，噪声扑出来太多该怎么摁住，还有那个门禁的阈值在分着阶段朝紧里收的时候该怎么样去设，这两桩事情顶要紧的那条路子，就是头一步先把噪声给拨拉开了，接着去把基线给立起来，末了再一截一截地勒紧。在刚开头的那个时节里，先伸手去挡住那些新长出来的问题，到了中间的一程呢，就照着风险的高矮去把门禁的劲儿给加上去，等到后头那一段，再去推着从前堆下来的告警一点一点儿地往下缩。这么一来，MISRA的检查才算不会变成一盏谁都不乐意去瞧的CI红灯，倒能实实在在帮到项目去把代码里头的那些险处给把住。