SonarQube 生产落地案例

五、生产落地案例

案例一：存量老项目先在「新代码」上见效。背景是一个多年的单体 Java 项目，代码量大、测试少。团队第一次接入时把门禁条件直接设成「整体覆盖率不低于某个值、整体重复率不高于某个值」，结果每次分析都是红的，开发同学很快学会了一句「Sonar 那个红的是历史问题，不用管」——工具彻底失效。做法是调整为三阶段推进：第一阶段，把 New Code 定义为「某个基线之后」，门禁只作用于新代码，条件设为「新代码新增 Bug 为 0、新增漏洞为 0」，覆盖率暂时不卡；第二阶段，随着新代码逐步有测试，把新代码覆盖率纳入门禁，阈值从很低的值起步，每季度上调；第三阶段，用「技术债增量」作为辅助指标，观察整体趋势是否在下降，而不是要求它立刻归零。关键配置上，把 sonar.exclusions 补齐（生成代码、第三方库、前端构建产物全部排除），并修复了 Java 项目漏配 sonar.java.binaries 导致部分规则不生效的问题。效果是门禁从「人人无视」变成「真的会拦人」，且新代码的问题密度持续下降。坑与解决：一是令牌明文写在流水线脚本里，后来改成密钥变量注入并吊销了旧令牌；二是覆盖率始终为 0，排查发现是 JaCoCo 报告路径配错、且测试与源码目录没分开，导致扫描器找不到报告；三是有人为了过门禁把规则关掉，后来把 Quality Profile 的修改权限收到少数人手里，任何规则变更要留记录。

案例二：多项目统一度量与定期质量回顾。背景是同一个部门下有十几个仓库，语言不一，质量水平参差，靠人工统计不现实。做法是：用 Web API 在流水线里自动创建项目与分析令牌，各仓库复用同一套 Quality Profile，保证「同一语言用同一把尺子」；每周把各项目的关键指标拉出来做一次回顾——新增 Bug 数、新增漏洞数、新代码覆盖率、重复率、技术债增量。回顾的关注点不是排名，而是找「为什么这个仓库的重复率在涨」「为什么这个模块的覆盖率一直上不去」，把结论落成具体动作。关键配置是把门禁条件做成共享的模板，避免各项目自行放宽；同时把 SonarLint 推给开发同学，让问题在编辑器里就暴露，而不是等流水线。坑：一是分析耗时影响流水线体验，大项目单次分析时间较长，后来把分析安排在与部署并行的阶段，并开启了缓存目录；二是不同 Java 版本的项目共用一份 Profile 导致规则报错，后来按 JDK 大版本拆成两份 Profile；三是指标被当成 KPI 后出现「为指标而改代码」，比如把长函数机械拆成多个短函数却不改内聚性，后来明确指标只用于发现线索、不用于考核个人。

漏洞分级与修复闭环：SonarQube 的问题按 Blocker / Critical / Major / Minor / Info 分级。落地时的处理原则是：Blocker 与 Critical 当次必修，尤其是安全类，不修不能合并；Major 限期修，纳入迭代排期；Minor 与 Info 批量处理或直接调低规则等级。每条问题要有归属人（按代码提交记录建议指派人）、修复方案、验证方式，修完重新分析确认该问题消失才关闭。要避免两种反模式：一是把规则大量关闭来「让门禁变绿」，二是把门禁阈值定得太松以至于从不报警——两种做法都会让平台的投资白费。