技术管理者---提升研发代码质量---代码检查工具Sonar

本文是《技术管理者---提升研发代码质量》系列文章第二篇，第一篇整体介绍请看博文《技术管理者---提升研发代码质量---总体方法论》。本文重点讲三部分内容：1）sonar是什么，研发体系如何利用sonar提供代码质量；2）开发过程中如何使用Sonar保证代码质量；3）sonar与Jenkins持续集成，持续闭环研发代码质量。

 

Sonar是什么？能干什么？

Sonar是一个用于代码质量管理的开源平台，用于管理源代码的质量 通过插件形式，可以支持包括java,C#,C/C++等多种编程语言的代码质量管理与检测。Sonar可以从以下7个维度检测代码质量：

• 不遵循代码标准：包含CheckStyle,Findbugs等等代码规则检测工具
• 潜在的缺陷：包含CheckStyle,Findbugs等等代码规则检测工具
• 糟糕的复杂度分布：检查过高复杂度的文件、类、方法
• 重复：重复代码检查
• 注释不足或者过多：
• 缺乏单元测试：
• 糟糕的设计：找出包与包、类与类之间相互依赖关系

先放几个Sonar能发现的问题常见问题代码截图：

能够发现Sonar检测出很多研发质量不规范、非常容易出错的地方，作为研发管理者你肯定会想：这么好的工具，我们研发团队一定要使用起来。 这种想法非常好，但一个更关键的问题是：研发团队如何使用Sonar，如何和现有研发流程规范结合起来，这就需要将Sonar检测结果作为现有研发流程中的重要一环，才能让Sonar长期发挥作用。 不然只会出现如下的情况：研发经理说下个版本开始我们使用Sonar检测代码啊，只有检测通过了才行。 相信我，过2个月之后，你将发现没人按照你说的去执行。

要想让Sonar与现有研发流程紧密结合、提升研发质量，我们先来了解一下Sonar家族体系。

然后再来看看Sonar报告发现问题的种类

最后来看作为技术管理者，如何将Sonar作用在研发流程与持续集成环境当中

PS：上面讲解的研发流程维度使用Sonar的方式需要人的参与，不是最好的方案，最好的方案是开发人员在提交代码到Git的时候，自动触发Sonar增量检测，并能将错误信息返回到Git提交客户端，这种方案需要修改Git客户端与服务器端逻辑，代价太大了。目前业界有一种Sonar+Gerrit配合使用，能够达到上面的效果，只是使用Gerrit的代价也较大，需要同步Gerrit与GitLab的仓库、同步账号、同步权限等一系列的同步，非常容易因为同步不成功而导致整个代码提交、打包产生问题。故博主所在公司使用上图中的方案。

下面讲解如上研发体系使用Sonar做静态代码检测的两种整合方案，详细的实施方案。

开发过程中如何使用Sonar保证代码质量

Idea开发中安装Sonar插件《SonarLint-3.4.0.2532.zip》，菜单路径“Idea-->File-->Setting-->Plugins-->Install plugin from disk”，截图如下

安装完成之后，重启Idea，就能看到当前打开文件的检查报告结果，如下：

点击右侧Report，可以检查整个工程Sonar扫描结果

这样每位开发同学在提交代码前都会将本次任务里涉及到的代码做Sonar静态检查，检查通过后截图到自测报告中，完成的规范与研发流程强关联。

 

Sonar与Jenkins持续集成，持续闭环研发代码质量(安装Jenkins、SonarQube，并整合服务每天出自检报告)

安装Jenkins，网络上有很多安装Jenkins的完整文章，读者可以直接参照，本博文里面就不详细介绍了，可以参考：《https://blog.csdn.net/sms15732621690/article/details/71336224》

安装SonarQube服务，网络上也有很多完成的文章，读者可以直接参照，本博文里面就不详细介绍了，可以参考：《https://www.cnblogs.com/ding2016/p/8065241.html》。

这里面有几个坑特别要注意：

• 要想运行SonarQube，操作系统至少要有2G空闲内存，不然服务可能会无缘无故的进程没有，特征如下：

2018.09.06 17:11:31 INFO  app[][o.s.a.SchedulerImpl] Process[ce] is up
2018.09.06 17:11:31 INFO  app[][o.s.a.SchedulerImpl] SonarQube is up
2018.09.06 17:26:39 WARN  app[][o.s.a.p.AbstractProcessMonitor] Process exited with exit value [es]: 137
2018.09.06 17:26:39 INFO  app[][o.s.a.SchedulerImpl] Process [es] is stopped

• 启动好SonarQube的时候，切记把token记录下来，后面在和Jenkins整合的时候需要。

下面介绍Jenkins与SonarQube的整合方式，根据官方文档《https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Jenkins#AnalyzingwithSonarQubeScannerforJenkins-AnalyzingwiththeSonarQubeScanner》介绍，整合方式4种方式。 博主所在企业实用第一种“Analyzing with the SonarQube Scanner”，大部分的互联网企业，应该是采用第三种” Analyzing with SonarQube Scanner for Maven or Gradle”。下面详细介绍第一种整合方式详细配置过程(也可以先看官方文档做了解)。

• 配置Jenkins系统管理--->插件管理--->安装”SonarQube Scanner for Jenkins”(如下),安装成功后重启Jenkins

• 配置Jenkins系统管理--->系统设置--->配置” SonarQube servers”(如下),注意这里需要应用前面安装SonarQube的Token。 其他的配置正常进行(Java、Git等)

• 新建“构建一个自由风格的软件项目”任务，分别配置好“GitHub”、”源码管理”、”构建触发器”,”构建环境”,”构建类型Execute SonarQube Scanner”分别截图如下：

 

上面的sonar.sources用于设置项目的源码地址，一般实际项目上，源码都是在很多子工程的，所以这里需要写多个，多个源码地址用,号隔开，路径可以使用相对路径。

• 配置完成后点击”立刻构建”构建成功后即可看到结果，可在Jenkins中快速链接到SonarQube中的结果。截图如下：

 

至此，大功告成，让此静态检查持续集成方法，提升你们团队的 代码质量吧。