对代码质量进行检查

2021-10-27

3分钟阅读时长

开发技术 , 集群部署 , K8s , Docker

Django方方面

今天习得了一个不错的项目代码质量检测工具，并且在自己的 IDE 上进行安装，这一实践不要紧，感觉还是很不错的。后来查了文档，这个工具不仅可以在 IDE 上来使用，在项目的持续集成部署上面，依然有用武之地，可以提高项目的代码质量。也就是说在你项目根目录下的 gitlab-ci.yml 文件中把它作为一个持续集成部署中的一个 pipeline，就可以对你上线代码的质量进行把控。这个工具的名字就是 SonarQube，同时针对 JetBrains 也有一款起相同作用的工具 Qodana。

这篇文章主要对 SonarQube 这个工具做针对性介绍，文章分为四部分。第一部分介绍这类工具通常使用你所获得的收益是什么。第二部分阐述搭建工具运行环境所需做的准备。第三部分阐述详细的部署过程。最后一部分进行总结。

一.用这类工具的收益是什么？

简单直接，这些工具一般会对代码上什么样的问题进行提示？

1.不遵循标准的。比如说一些对于 list 数据类型的非空检测，我之前是比较习惯用 xx.size()>0 来判空的，你用这个工具，就会提示，让你个性成 xx.isEmpty()的方式；

2.潜在的缺陷。比如你有安装 checkstyle 格式检测工具，给出你的提示，如导入未使用的包等。

3.高复杂度的代码分布。可能该进行抽象的类，方法没有提出来，所有代码都面向过程的写在一个文件里，这个时候会给你提供优化建议。

4.冗余代码及重复。比如说代码实现的方式改变了，之前代码为了防止产品再把需求改回来，进行了注释，会给你提示，去掉这些冗余代码。

5.注释不足或者是注释过多。这个就不多解释了。

6.没有单元测试。正常对于开发功能，都有对应此处功能的测试方法。

7.糟糕的设计。这个在 java 中尤其明显，java 各个层逻辑层面肩负的功能是非常清晰的，如果想让参数在各层畅行无阻恐怕是不现实的，所以就涉及了结构上各层的参数的传递。此时遵循标准就是理想的处置方式，而强行复用就显得收益不足，还让整个结构变得混乱。

二.环境准备

Java 环境
Maven 环境
SonarQube 平台
gitlab
Jenkins 平台或者是 gitlab-runner 这个 gitlab 代码托管工具的扩展，本文针对 gitlab-runner 进行说明
数据库（例如 mysql）

以上安装，如有问题可自行谷歌。

三.部署过程

编写 gitlab-ci.yml 配置文件

gitlab 原生安装
stages
- test

job1:
stage: test
only: - master
script: - sonar-scanner -Dsonar.projectKey=abc -Dsonar.host.url=<http://172.18.16.50:9000> -Dsonar.login=6d190aebe5c01fd18f22c212f47fc5f657a29f1d -Dsonar.java.binaries=.

gitlab docker安装
image:
  name: sonarsource/sonar-scanner-cli:latest
  entrypoint: [""]
variables:
  # 在sonarqube中创建项目时生成的TOKEN
  SONAR_TOKEN: "09904533c04eee38bc6c6d5b4acfc4fb73865626"
  SONAR_HOST_URL: "http://192.168.102.27:9000/"
  GIT_DEPTH: 0
sonarqube-check:
  stage: test
  script:
    # sonarqube中项目的标识
    - sonar-scanner -Dsonar.qualitygate.wait=true -Dsonar.projectKey=firsttest -Dsonar.java.binaries=.
  allow_failure: true
  only: # 仅检测master合并请求和master分支代码提交，sonarqube-ce版本只支持分析dev分支
    - merge_requests
    - dev