1、SonarQube介绍
SonarQube 是一个开源的代码质量管理平台,用于静态代码分析、代码审查、代码可视化和报告生成。它提供了一套工具和功能,帮助开发团队监控代码质量、识别和解决代码中的缺陷、漏洞和技术债务。
SonarQube 主要功能包括:
1.静态代码分析:SonarQube 使用静态代码分析技术检查代码,并识别潜在的代码质量问题,如代码重复、代码规范违规、安全漏洞、性能问题等。
2.代码审查:开发团队可以使用 SonarQube 进行代码审查,提供评论、建议和改进,以改善代码质量和可维护性。
3.实时报告:SonarQube 提供实时的、可视化的报告和仪表板,展示代码质量指标、问题趋势、技术债务等信息,帮助团队了解代码质量状况并采取适当的措施。
4.集成支持:SonarQube 可与各种版本控制系统(如 Git、SVN)、持续集成工具(如 Jenkins、TeamCity)、项目管理工具(如 Jira)等集成,以便在开发工作流程中无缝地进行代码质量管理。
5.可扩展性:SonarQube 具有丰富的插件生态系统,可以通过安装插件扩展其功能,满足不同团队和项目的需求。
总的来说,SonarQube 是一种强大的工具,可以帮助开发团队提高代码质量、减少技术债务,并促进持续改进的软件开发过程。
2、SonarQube安装
我安装的版本是SonarQube9,SonarQube9需要java11和postgresql支持,安装环境是windows11。
涉及的软件可以在这里下载:【免费】《SonarQube9安装与使用》涉及的软件合集资源-CSDN文库
2.1、安装postgresql
先下载好postgresql,然后点击安装。
创建一个叫sonarqube的数据库。
创建一个叫“my_schema”的Schema。
2.2、安装SonarQube
下载好后直接解压缩就行了。
修改一下这两个配置文件。
sonar.properties
wrapper.conf
启动sonarqube(需确保系统当前的java为11)
启动的过程中有可能会遇到这个问题,启动失败了。
解决方法是关闭所有java程序。任务管理器里面搜索java,然后把相关任务全部结束掉。
再次启动,sonarqube就启动成功了。
浏览器访问:http://localhost:9000/
因为原版是纯英文的,为了方便查看,可以安装中文汉化包(不建议直接浏览器翻译,一些专有名词翻译出来会比较奇怪)。
不过因为在线安装的中文汉化包只支持10以上的sonarqube。 因此我们可以去github上下载对应版本的汉化包。Releases · xuhuisheng/sonar-l10n-zh · GitHub
重启一下SonarServer就行了。
以上SonarQube服务端已经配置完成了。接下来要配置的是本地开发工具中的SonarLint,我以Intel Idea为例。
2.3、在Intel Idea中配置SonarLint
首先要在Intel Idea中安装SonarLint
因为我的SonarQube是9,而Plugins Marketplace中的SonarLint是最新的10以上的版本。因此我们可以去这个网站上找SonarLint插件的历史版本。
SonarLint - IntelliJ IDEs Plugin | Marketplace
我用的是SonarLint8.5这个版本。不同的版本有啥区别呢?反正我看下来就是图标的区别。
我比较喜欢SonarLint8的图标,所以我就安装了SonarLint8.5
安装好后,重启Intel Idea。
到这里,我们本地的SonarLint和服务端的SonarQube就全部配置完成了!
3、使用SoarLint扫描代码
3.1、本地分析代码
我们可以看到SonarLint对代码质量的扫描报告。
红色标识的代码(阻断,严重,主要)是一定要改掉的,其他的则可以忽略。
3.2、Meavn命令扫描代码并上传至sonarqube
因为是SonarQube9需要java11支持,所以需把Intel Idea中的java版本切换到11
在pom.xml添加如下配置
<properties>
<java.version>11</java.version>
<!-- SonarQube服务器地址-->
<sonar.host.url>http://localhost:9000/</sonar.host.url>
<!-- 访问令牌或⽤户名密码 -->
<!-- <sonar.token>squ_0885801988f86axxx9639071f2348bb367e320d</sonar.token>-->
<sonar.login>admin</sonar.login>
<sonar.password>123456</sonar.password>
<!-- 不扫描pom.xml和test目录下的文件-->
<sonar.exclusions>pom.xml,src/test/**/*</sonar.exclusions>
<!-- <sonar.projectKey>root_erp_5xxx0128-8cf0-4de3-905a-51df06a56403</sonar.projectKey>-->
<sonar.projectName>Erp</sonar.projectName>
<sonar.qualitygate.wait>true</sonar.qualitygate.wait>
</properties>
在终端执行命令:mvn sonar:sonar 或者 mvn clean compile sonar:sonar
从报告中可以看出,代码还是有蛮多问题的。
4、总结
因为公司的gitlab CI/CD整合了SonarQube,使得代码质量不过关代码合不上去。所以我才接触到了SonarQube。SonarQube也用了有小半年的时间了,总体感觉下来Sonar对于代码质量的提高确实蛮有用的,但代价就是增添了许多工作量,尤其是一些老的项目,可能当时开发的人不在了,注释也不完整,如果你接手的话,哪怕就是修个bug,或者改个参数,加个小功能,可能就一两个小时就开发好了,但因为Sonar的存在,你的代码想要合到测试分支发布测试环境的话,你不得不花上一两天甚至一两个星期的时间,去重构整个项目的代码,使其符合Sonar制定的代码规范。当然这也更加体现了微服务的好处,微服务对大业务拆分成一个个小的服务,小服务的项目代码少,更好改更好重构,更好一个个测试。如果单体项目的话,代码量过于庞大,强行上Sonar的话就是在找死。
说到代码规范,我最早用的是Alibaba Java Coding Guidelines这个插件,这种插件校验属于即时校验,主要就是查一些语法规范命名之类的。查不了代码重复率和漏洞缺陷这种。
SonarQube和SonarLint虽然可以自定义规则,不过有几个默认的规则反正我觉得蛮不合理的。比如doc注释,其实注释只要直白明了看得懂就行了,尤其是我们都在讲“代码即文档”嘛!强行要求去加一些有的没的注释也会影响代码整体的简洁。还有就是对一个函数的return数量做限制,一个函数return最多不能超过3个。这个也不合理。switch case中每个case的代码行数不能超过三行,也不合理。以及最让我觉得不合理的是对一个类文件的代码行数有限制。一个类的有效代码行数不能超过750行。实际中很多service类都是上千行了。再加上又有要求每个函数的行数不能超过75行,然后每行不能超过120个字符。许多旧代码无论类还是行还是每行字符数量都超了好多,再加上Sonar会有代码重复率的校验,因此重构旧代码是个非常麻烦庞大的工程。