在代码扫描刚刚落地的时候，有两个问题是挺常碰到的，一个是SonarQube扫出来的问题，到底要怎么去分配给具体的人来处理，另一个是，这些问题它的状态变来变去，又要怎么去管，扫描出来的结果一多，要是没有个明确的负责人，那些问题就会长时间地挂在列表里面；可要是大家随便地就把状态给改成了已接受，或者是误报，那到了后面，再去搞质量门禁、版本复盘，还有审计说明的时候，就会很难说得清楚了。SonarQube在分析的时候，它会试着把新发现的问题，自动分配给，最后改过那一行代码的人，但这有个前提，就是代码提交时候用的那个账号，得能跟SonarQube里面的用户，关联得上；要是关联不上，那它就会去用项目里设好的那个默认处理人。

　　一、问题要怎么分配给处理人

　　SonarQube分配问题这件事，不能全靠着系统自己去判断，自动分配，比较适合用来处理日常新增的那些问题，但对于历史上遗留下来的问题、公共模块里的问题、目录级别的问题，还有那种好几个人都在维护的代码，还是得由项目组自己，手动去调整。

　　1、先把用户和代码提交的账号，是不是对得上，给确认好

　　可以进到个人的资料页，或者是管理员的用户管理页面里面，去查一下，SonarQube账号里头的邮箱、登录名，跟Git或者别的版本管理工具，提交信息里面的是不是一样的，官方的文档里有说明，SonarQube会根据版本管理工具的账号，去跟用户的登录名、邮箱做关联，只有这个关联搞好了，新出来的问题，才更容易被自动分配到对应的人头上去。

　　2、在问题列表里面去手动分配

　　进到项目页面，去把问题列表给打开，然后靠着严重的级别、规则的分类、文件是在哪个路径下、当前是什么状态、还有现在是谁在处理，这些条件去把问题给筛出来，找到具体的问题卡片以后，去点一下那个处理人的名字，或者是还没分配的按钮，在弹出来的列表里面，去选一个具体的人；要是你暂时还不想指定给谁，那也可以去选那个取消分配的选项。SonarQube官方的管理说明里，也是明确支持去分配、重新分配，还有取消分配问题的。

　　3、同一类的问题，可以一批一批地去分配

　　要是同一个模块下面的问题，全都该归一个人去处理，那就可以先按照路径、规则、严重的级别去筛选一下，然后把这些问题都给勾上，去点一下那个批量修改的按钮，去选上分配这一项，再统一地把处理人给定下来，在做这种批量操作的时候，一次别把范围选得太宽了，那些公共的代码、测试的代码、还有自动生成出来的代码，最好是分开来处理，免得把那些本不该由他处理的问题，也一股脑儿地压到了同一个人的身上。

　　4、按照模块的责任，去把分工给补充好

　　像公共库、底层的框架、接口适配层这一类的代码，最后在那个地方提交的人，可不一定就是真正该对它负责的人，这种情况，是可以按照各个模块的实际负责人，去重新把问题给分配一下的，在必要的时候，也可以去给问题打上一些标签，就比如，已经评审过了、是历史遗留的、是归这个模块的负责人管的，这样后面再去筛选，或者是复盘的时候，就方便多了，SonarQube也是支持的，它可以给问题去打上标签，加上评论，用这些东西来辅助后面去查找，或者是来表示，它现在正处于一个什么样的处理阶段。

　　二、问题的状态流转要怎么管理

　　SonarQube里对问题状态的管理，要围着真实处理的结果来做，状态这个东西，它不是为了让你把问题列表给清空，才去改的，而是为了要去说明，这个问题到底是不是真的需要修、它是不是一个误报、是不是打算暂时先放一放，还有，在后面的扫描里面，是不是已经确认它被修好了。

　　1、对于新出现的问题，就让它的状态保持在“打开”

　　“打开”这个状态，就是一个问题在第一次被扫出来以后，它最开始的初始状态，开发的人接到问题以后，应该是先去判断，它是不是一个真实存在的毛病、它会不会影响到当前的这个分支、它是不是落在了新代码质量门禁的那个范围里面，可不要一看到有问题，就直接把它给改成了“已接受”，因为这么干，是很容易把那些真正需要去修的缺陷，给盖住了。

　　2、只有那种暂时不打算去修的问题，才去用它

　　要是问题已经被确认是真的了，但是，因为它是历史代码、现在正卡在版本发布的窗口期、重写的成本太高了、或者是兼容性方面的原因，反正暂时是没法去动它了，那这个时候，才可以去把它给改成“已接受”，并且，要把原因，还有后面打算在什么条件下再处理它，都给写清楚了，官方的文档里也说了，“已接受”这个状态，是用在那些决定了要晚点再修，或者干脆就不修的问题上的，SonarQube在给代码评级的时候，是会忽略掉这一类问题的。

　　3、只有确认了是工具自己判错了，才用“误报”这个状态

　　“误报”这个东西，只能是用在，分析出来的结果，它确确实实是错的情况底下，就比如说，那条规则它本来就不适合这个框架的写法，或者是，上下文的逻辑能证明，那个风险是根本不可能发生的，在把它标记成误报的时候，要把你做出这个判断的依据给写清楚了，可千万不要把那些，只是因为难改，不想去修的问题，全都给打成了误报，官方的文档里有说明，“误报”就是用在分析误判这种场景的，而且，做这个操作，是需要有对应权限的。

　　4、等到代码修完了以后，让下一次的扫描，自己去把它给变成“已修复”

　　一个问题在代码里面被修掉了以后，是不太建议，靠人工去写一句“已修复”，然后就觉得完事了，应该是要去把代码给提交上去，然后重新跑一遍扫描，让SonarQube在后面的分析当中，自己去确认，那个问题已经不再能被扫出来了，到了那个时候，系统就会把原先的那个问题，给自动认成是“已修复”了。官方的生命周期说明里也讲了，“已修复”这个状态，就是由SonarQube在后面的分析里，发现那个问题已经不存在的时候，自己去设上的。

　　三、问题闭环的记录要怎么留下来

　　对SonarQube的问题去做闭环，不能光是盯着它的状态变了没有，还要把整个判断的过程都给留下来，特别是像安全的漏洞、会阻断流程的那种级别的问题、还有反反复复老是出现的问题，这些东西，到了后面，是经常会被质量的负责人，或者是客户追着问的。

　　1、在评论里面，去把处理的依据给写清楚

　　对于那些要修复的问题，要去把提交的内容，还有你是怎么去验证它的方式给写下来；对于那些被标成“已接受”的问题，要去把为什么暂时放着的原因、它影响的范围有多大，还有计划在什么时候去处理它，都给讲明白了；对于那些被认定为“误报”的问题，要去说明白，它为什么就一定不会被触发，SonarQube是支持的，可以在问题里面去添加评论，并且在活动的记录里面，是能查看到这些相关的东西的。

　　2、把问题和代码的提交给关联起来

　　在你去处理问题的时候，在提交代码的说明里面，是可以把SonarQube的问题编号、规则的名字，或者是它属于哪一个模块，给写进去的，这样一来，到了后面，你从一个问题出发，就能找到对应的代码改动；从代码的改动那边，也能反过来追到问题的来源，就不会到最后，只剩下一个干巴巴的状态摆在那里了。

　　3、要定期地去复查，那些还没有被关掉的问题

　　在每一个迭代快要结束之前，按照“打开”的、“已接受”的、“误报”的、处理人是谁、还有严重的级别，这些条件去筛一遍，对于那些还“打开”着的问题，要去看一看，是不是已经超过了期限；“已接受”的问题，要去看看，当时暂时不修的理由，是不是到现在还能站得住脚；“误报”的问题，要去看一看，在规则或者是代码变了以后，是不是需要把它给重新打开，SonarQube也是允许，把那些已经被“接受”了，或者是标成了“误报”的问题，再给重新打开来的。

　　4、把那些老是高频出现的问题，给沉淀到评审的清单里面去

　　要是同一种类型的问题，老是在那里反反复复地出现，就比如，空指针、资源没被释放掉、重复的代码、异常没有被处理，那就不应该只是靠着扫描完了以后，再去修它，而是可以把这一条规则，给加到代码评审的清单，或者是编码的规范里面去，在提交代码之前，就先把它给拦一道，这样做，能减少后面集中起来返工的工作量。

　　总结

　　关于SonarQube的问题要怎么去分配给处理人，这里面很关键的一步，就是先要让版本管理工具的账号，跟SonarQube里面的用户给对应起来，然后，再结合着各个模块的实际负责人，去手动分配，或者是用批量的方式去调整；而SonarQube的问题状态流转又要怎么去管，它的关键则在于，“打开”是用在等着去处理的，“已接受”是用在有理由先放一放的，“误报”只能用在确认是工具判错了的时候，而“已修复”呢，就得靠后面的扫描，自己去确认，只有把分配、状态、评论、提交的记录，还有重新扫描的结果，这所有的事情都串到一块儿了，一个问题的闭环，才算得上是真正能说得清楚了。