sonar与指标解读

Sonar

整体

要先在服务端更新插件，才能在本地使用！！！Sonar是服务端通过plugin进行数据解析和转义的，所以sonar形成了类似于拉docker的C-S扫描模式，必须服务端先行。

Android

通常是按照$SONAR_URL/documentation/analysis/scan/sonarscanner-for-gradle/ 来配置。

坑

• gradle 6.1.1要指定jdk11才能跑起来，与文档写的不一致
• 测试代码大概率会有问题，对于unittest加-DskipTests=true参数跳过
• 对于AndroidTest，在gradle中手动disable

- tasks.whenTaskAdded {task ->
   if(task.name.contains("AndroidTest") || task.name.contains("androidTest")) {
       task.enabled = false
   }
}

• 文档里的多module说明是有误导性的，在一个大项目中执行sonarqube并不会构建一个整合报告，而是每个子项目一份。即便是sonar.projectName都一样，也是覆盖关系，不是merge
• 可以利用web api整合各种项目的结果，常用的是
  api/projects/search?q= 和 api/measures/component。后者要传metricKeys，可以在sonarqube的结果页抓包确定每个metric的key。

iOS

不要用idean的那个plugin，跟sonarqube server 9.x有冲突，起不来服务。用https://github.com/sonar-next/sonar-swift。后者的核心数据是lizard、infer，和前者不太一样。

• idean的脚本也不要用，里面会有如下问题：
  • xcodebuild build-for-testing是要有地方跑ut的，大概率会有依赖不支持模拟器，而CI的机器上只能模拟器，直接跑不通
  • oclint缺COMPILER_INDEX_STORE_ENABLE=NO，报错

flutter

用https://github.com/insideapp-oss/sonar-flutter，问题不大。而且支持整合多个子project。如果根目录不是app，则需要同时指定

sonar.sources=aaa
sonar.projectBaseDir=bbb

指标选取

以下为论文结论摘要。

code smell

无效 java code smell列表

code smell	无效的理由
所有tag包含spring的	非客户端环境
“Bean Validation” (JSR 380) should be properly configured	非客户端环境
“Class.forName()” should not load JDBC 4.0+ drivers	非客户端环境
“private” methods called only by inner classes should be moved to those classes	更应该考虑合理归属
An open curly brace should be located at the beginning of a line	不符合客户端code convension
Default annotation parameter values should not be passed as arguments	不传default增加了理解复杂度，不利于代码重构

太多了，待补充

Issues

太多了，待补充

圈复杂度

• 圈复杂度比Essential Complexity更能预测bug。nasa
• 圈复杂度的合理阈值是20（很差）和10（有危险）。nasa
• 圈复杂度密度对维护成本有超过一半的影响力。DoD

Sonar中没有，但很有用的指标

• Module Design Complexity，用以确定模块划分合理程度。
• mccabe是个好东西。