在给QAC划定分析范围的时候，关键是要先分清楚，哪些代码是必须要进到规则检查里面去的，又有哪些，只不过是第三方的库、机器自动生成出来的代码、历史归档留下来的东西，或者是临时构建出来的产物，QAC的命令行工具，它可以去分析单个的文件，也可以去分析整个QAC的项目，或者是CMA的项目，在默认的情况下，它只会去把那些发生了变化的文件，还有那些依赖着它们的文件，或者是相关的设置，给重新分析一遍；要是你动手去执行了清理的操作，那它就会把之前分析的结果给删掉，等到下一次再去跑的时候，就会触发一次从头再来的重新分析。

　　一、分析范围要怎么去划定

　　QAC的分析范围，可不要直接就把它跟代码仓库的范围划上等号，代码仓库里面，放着源码、脚本、生成出来的文件、配置文件，还有从第三方拿来的依赖，真正需要进到像MISRA、AUTOSAR C++，或者是项目自己定的那些规则检查里面去的，通常都是产品的源码，还有那些需要你拿出交付说明的、自己研发的模块。

　　1、要先去照着交付的边界来划分

　　先要去确认好，这一次的分析，对应的是哪一个软件的版本、哪一块ECU的模块、哪一个功能包，在交付范围以内的那些源文件和头文件，是应该要优先给放进来的；而那些用来做测试的桩、示例的代码、工具的脚本，还有临时的目录，就不要在默认的情况下，把它们也给混进去了，只有这样，最后产出来的报告，才能跟要发布的那个版本，对应得上。

　　2、再接着去照着责任的边界来划分

　　自己写的代码、供应商给的代码、开源的库，还有编译器自己带的头文件，这些东西，是要分开来处理的，对于第三方的代码，一般是不太建议，把它跟自己写的代码，放在同一套问题的闭环里面去的，不然的话，告警的数量就会像吹气球一样地膨胀起来，开发的团队，也很难去对这些多出来的东西负责。

　　3、要把那些必须要用到的头文件依赖，给留下来

　　在去划定排除范围的时候，可不能只盯着文件夹的大小来看，有些头文件，虽然它们并不会被直接交付出去，但是，它们会去影响到宏的定义、类型的解析，还有编译的配置，QAC的项目，是需要从项目构建的那个环境里面，去把源文件的选项给提取出来的，这样才能去把分析的项目，给正确地填充好，所以，你可以去把那些跟分析无关的实现文件给排除掉，但是，不要随随便便地，就去把那些必须要用到的包含路径给删掉。

　　4、去照着模块，来建立起不同的配置

　　当一个项目变得非常庞大的时候，就可以去按照像基础软件层、应用层、诊断、通信、控制算法，这样的模块，去把分析的范围给拆分开来，让每一个模块，都单独地去出一份它自己的报告，到了最后，再把这些问题的状态，给汇总到一起去，用这种办法来做的效率，通常是要比那种一次性，就把整个仓库全部分析一遍，要来得稳当一些的。

　　二、分析范围太大了，耗时间特别长，要怎么去优化

　　QAC跑起来特别耗时间，一个比较常见的原因，就是一次性地去扫了太多压根儿就不相关的文件，又或者是，每一次都触发了那种全量的重新计算，在做优化的时候，要先去把分析的范围给缩小，然后再去处理增量、缓存，还有构建配置这些事情。

　　1、要先去把那些不相关的目录给排除掉

　　去把像编译输出、生成文件、第三方库、测试用例、示例代码、历史备份，这一类的目录，从分析的范围里面给踢出去，对于那些机器自动生成出来的代码，要是确实有检查的必要，那也最好是去给它单独建一个分析范围，不要让它跟手写出来的代码，混到一起去，免得影响了问题的统计。

　　2、要优先去用增量的分析

　　在持续集成的流水线里面，可不要每一次，都去把项目给清理一遍，然后再去跑全量的分析，命令行的分析工具，它在默认的情况下，是会去对着那些发生了变化的文件，还有它们的依赖，来做重新分析的，而清理项目的这个动作，是会逼着下一次的分析，变成强制性的全量重新分析的，所以，只有在规则包、编译的配置，或者是基线发生了变更的时候，才需要去考虑，要不要来一次干干净净的全量分析。

　　3、去控制一下同时跑好几个配置的情况

　　要是同一个工程，在同一时间里面，同时去跑了好几个不同编译配置的分析，那它花掉的时间，是会明显地往上涨的，在对那种带着好几个配置的项目下命令时，是可以通过指定的方式，去选一个非默认的配置来跑的，在日常的流水线里面，可以就只去跑当前分支所对应的那一个配置，等到快要发布之前，再去把那完整的一整套配置，都给跑一遍。

　　4、去把生成报告和分析这两件事给分开来做

　　生成报告这件事，它也是会占掉不少时间的，尤其是当HTML格式的、那种详细的清单，还有给管理层的报表，这几种东西，同时都在往外输出的时候，报告的那个命令，它是基于已经跑完的分析结果，再去生成报告的，所以，在日常的构建里面，可以就只让它去输出一份最关键的摘要，等到里程碑的版本，再去生成那种完整的报告。

　　三、分析范围被优化了以后，要怎么去确认它是有效的

　　当范围被缩小了以后，不能光看着跑分析的时间变短了，就觉得没事了，还得再去确认一下，那些关键的代码，是不是真的没有被误伤给排除出去，要不然的话，流水线是跑得快了，可到了评审的时候，人家问起来覆盖的范围，你就怎么也解释不清楚了。

　　1、去跟文件的清单对照一下看看

　　把这一次被纳进了分析范围的那些源文件，给导出一份清单来，然后拿着它，去跟要发布的源码清单，还有构建时候用的清单，放在一起去对照一下，要是发现核心的模块有缺失，那就要赶紧把它给补回来。

　　2、抽着去查几个典型的告警

　　去挑几个你已经知道的、违反规则的问题，或者是以前就报过告警的文件，然后看一看，在优化完了以后，这些东西，是不是还能被扫描得到，要是它们从报告里面消失不见了，那就说明，你设的那个排除的规则，有可能是写得范围太宽了。

　　3、去把划定范围的规则给记下来

　　要把那些打算排除的目录、要纳进来的模块、配置的名字，还有它们都适用在什么样的场景里面，这些东西全给写进项目的说明文档里去，这样，到了后面，再去新增模块，或者是调整目录结构的时候，才能跟着去同步更新QAC的分析范围。

　　总结

　　给QAC划定分析范围，是不能把整个代码仓库，全都给一股脑儿地丢进去的，正确的做法，是先照着交付的边界，还有责任的边界，去把属于自己写的那些代码的范围，给确定下来，然后，再把那些必须要有的头文件，跟编译的配置，给保留住，等到发现范围太大了，导致跑分析的时间变得很长的时候，就要优先去把那些不相关的目录给排除掉、转去用增量的分析、把无关的配置给减一减，并且，把平日里要出的报告，做得轻便一些，等到优化全都做完了以后，还要记得，用文件的清单，还有历史上报过的告警，去反查一下覆盖的范围到底够不够，可不要只为了图一个快，就把那些很关键的代码，给弄丢了。