Coverity组件映射的设置，以及映射之后责任人信息不准确时的处理，其关键并不在于一开始就去给每一个人分配缺陷，而是需要先把代码的目录结构、组件的边界、规则的匹配顺序，还有负责人之间的对应关系，这几样东西给理顺清楚。组件映射这件事，通常是按照文件的路径规则，把代码划分到不同的组件里面去，这样一来，后续的缺陷筛选、报表的统计，还有责任的分配，才会有基础。

　　一、Coverity组件映射怎么设置

　　组件映射这种方式，比较适合被用在大型的代码库上面。比如说，一个项目里面，同时存在着驱动层、应用层、平台层、第三方的库，还有测试的代码，如果把它们全都放在一个大范围里面去查看，那么缺陷的责任，就很容易被搅和在一起。

　　1、先把组件的边界拆分清楚

　　不要一上来，就按照人员的名字去建立组件，最好是先按照代码的结构去进行拆分，比如分成base、driver、ui、service、third_party这样几类。组件的边界，应当尽量和代码的目录，还有团队的职责保持一致。如果代码的目录本身比较乱，那也可以先建立起粗粒度的组件，等到扫描跑过几轮，稳定下来了以后，再去进行细分。

　　2、把组件映射的规则创建出来

　　进入到【Coverity Connect】以后，在配置的区域里面，找到【Component Maps】，然后去新建，或者是选择一个已经存在的组件映射，接着再去给不同的组件，添加文件匹配的规则。规则一般是要围绕着文件的路径去编写的，比较常见的做法，是用目录的前缀，或者是正则表达式去进行匹配。比如某一个组件，它只负责src/driver/下面的代码，那就不要把规则写得太宽泛，否则相邻的目录，也可能会被一起归进去。规则越是细致，到了后面，就越是需要注意它们的优先级。

　　3、把它绑定到分析流上面去

　　组件映射这个东西，并不是单独存在在那里，就能够生效的，它还需要去和对应的stream进行关联。需要去检查一下【Projects and Streams】里面的stream配置，去确认一下，这个stream所选择的组件映射，是不是正确的。有很多责任人信息不准确的问题，其实并不是规则本身写错了，而是扫描的结果，被提交到了另外一个stream上面，又或者是stream所绑定的，仍然是那套旧版的组件映射。

　　二、Coverity组件映射后责任人不准确怎么办

　　在组件映射完成了以后，如果出现了责任人信息不准确的情况，先不要急着去改动人员的分配。需要先去确认一下，问题到底是出在了组件的归类、负责人的指派规则、SCM用户的映射关系，还是出在了那些历史遗留的缺陷，仍然保留着原来的人工判定状态上面。不同的来源，所导致的责任人偏差，处理起来的方式，也是不一样的。

　　1、检查一下文件，是不是被错误地归类到了组件里面

　　先筛选出一条责任人信息不准确的缺陷，去看一看它所对应的文件路径，是不是被归类到了正确的组件里面。如果文件被归错了组件，那多半是因为规则覆盖的范围太宽了、规则的排列顺序不合理，又或者是同一个文件，能够同时匹配到好几条不同的规则。在这种时候，需要先去调整组件映射的规则，不要直接去修改文件的负责人。否则的话，这一次靠手工改对了，到了下一次，新的缺陷出现时，还是照样会分错。

　　2、去检查一下规则的优先级

　　进入到【Component Maps】以后，对照着文件规则的排列顺序，去检查一下它的匹配逻辑。

　　同一条文件的路径，它是有可能会同时符合好几条规则的，这个时候，规则的先后顺序，就会影响到最终的归属。一般会比较建议，把那些更加具体的目录规则，放在靠前的位置，把那些用来兜底的规则，放在靠后的位置。比如src/driver/can/这一条，就应该被放在src/driver/这一条的前面，否则的话，那些细分的组件，就有可能会一直都匹配不到。

　　3、去检查一下负责人字段的来源

　　缺陷的责任人，它并不一定就只是来自于组件。如果系统开启了自动指派的功能，那还需要去检查一下SCM提交人的记录、Coverity的用户信息、用户的映射关系，还有负责人指派的规则，这几样东西是不是都能够彼此对得上。一种常见的问题是，提交记录里面的邮箱、账号名称，和Coverity的用户信息是不一致的，这样一来，就导致自动归属的功能，没有能够落到正确的人员身上；还有一种情况是，某些缺陷，在之前就已经被人手动地判定过了，责任人字段也就跟着被固定了下来，到了后面，就算组件的规则发生了变化，它也不会再按照预期，去自动地做出改变了。

　　三、组件映射维护时怎么减少后续偏差

　　组件映射这件事，并不是配置完一次，就可以放在那里，再也不去管它了。代码的目录，它是会做出调整的，团队的边界，也是会跟着发生变化的，就连第三方的代码，也有可能会被新增加进来。如果没有进行定期的维护，那么组件的归属，还有责任人的信息，迟早都是会发生偏差的。

　　1、给第三方，还有那些自动生成的代码，去做一个单独的处理

　　像third_party、generated、external，还有test data这一类的目录，最好是能够单独地去建立一个组件，又或者是，去明确一下，它们到底要不要被纳入到缺陷的责任分配里面来。否则的话，那些第三方代码里面的缺陷，就有可能会被分配到业务开发人员的头上，这样一来，既影响到了统计的结果，也容易让处理的进度，变得不够真实。

　　2、在做出调整以后，要去做一次样本的验证

　　每一次改完了组件映射以后，不要只是看着配置的页面上面，显示保存成功了，就觉得完事了。应当去挑选几个比较典型的文件路径，去验证一下，它们是不是都已经进到了预期的组件里面去了，然后再去看一看，对应缺陷的组件字段、责任人字段，还有筛选出来的结果，是不是都和预期保持一致的。如果项目的规模比较大，那就可以先用少量的规则，去进行测试，然后再去慢慢地扩大覆盖的范围。一次性写进去太多条复杂的正则表达式，到了后面再去排查的时候，是会非常费劲的。

　　3、把规则的说明保留下来

　　在组件规则的旁边，最好是能够保留一份说明，写清楚这个组件覆盖了哪些目录、是归哪一个团队来负责的，还有哪些目录，是不应该被匹配进来的。在人员发生了变动的时候，只去修改负责人的对应关系就可以了，不要随手就去改动文件路径的规则。规则的说明写得越是清楚，到了后面，接手的人员，就越不容易把组件映射给改乱了。

　　总结

　　Coverity组件映射应该怎么去进行设置，以及组件映射之后责任人信息不准确的时候，又该怎么去进行处理，这两件事情，是可以按照“先去拆分代码的组件，接着去编写文件路径的匹配规则，把stream绑定好了以后，再去验证一下归属的情况”，按照这样的一个顺序，来依次进行处理的。当责任人信息不准确的时候，要先去查看文件是不是被错误地归类到了组件里面，然后再去检查规则的排列顺序、SCM用户的映射关系，还有自动指派的那些规则。组件映射说到底，它是缺陷治理的一项基础配置，只要规则被写清楚了、排列的顺序被安排合理了、责任人字段的来源也被区分清楚了，那么到了后面，缺陷的分配，才不至于反反复复地出现差错。