Sonar平台简单调研

    最近需要准备将不同平台的静态代码检查集成到Sonar平台上，所以先做一个简单的了解。

一、 Sonar简介

  Sonar是一个用来管理源码质量的开源平台，可以从多维度进行静态代码检测。利用其可扩展性，sonar平台通过扩展插件的方式，支持不同测试工具、代码分析工具以及持续集成工具的集成，从而实现多种编程语言的代码质量检查和管理。正是因为它可以实现多种变成语言的代码检测，所以相对单一语言的检查工具或平台来看，稍显厚重，相对的可扩展性也就更强大。
  sonar作为一个代码质量管理和检测平台，既可以单独完成代码质量检查和结果分析，也可以通过插件获取其他静态代码检测工具的检查结果进行分析，因此，我们目前已有的Jenkins上实现的静态代码检查，通过插件和环境的配置，可以实现将检查结果集成到sonar平台，还可以将不同检测工具（Findbugs、OCLint、ESLint）的检查结果的统一化。

二、 Sonar的核心

SonarQube主要由以下部分组成：

SonarQube 组成	?
SonarQube Server	Sonar服务
SonarQube Database	数据库
SonarQube Plugins	插件
SonarQube Scanner	扫描器

  其中，SonarQube Scanner就是SonarCube用来进行静态代码检查的工具，通过它，将项目的代码读取并发送至SonarQube服务器中，才能让SonarQube进行代码分析。和我们目前在Jenkins上使用的ESLint等工具是一样的，只是在Sonar这里使用是将ESLint这些工具作为插件使用的。

SonarQube检测的核心：

SonarQube 检测的核心
检查代码是否遵循编程标准	命名规范，编写的规范等
检查设计存在的（潜在）缺陷	检测代码存在的缺陷
检测代码的重复代码量	展示项目中存在大量复制粘贴的代码
检测代码中注释的程度	是否源码注释过多或者太少
检测代码中包、类之间的关系	分析类之间的关系是否合理，复杂度是否合适

官网上给出的Sonar会检测出来的代码七大问题：

代码七大问题
糟糕的复杂度分布	文件、类、方法等复杂度过高
重复	大量的复制粘贴代码的出现
缺乏单元测试	Sonar会统计并展示单元测试覆盖率
没有代码标准	通过PMD，CheckStyle，Findbugs等这些代码规则检测工具规范代码编写
没有足够的或者过多的注释	避免过多的注释降低代码可读性
潜在的bug	通过PMD，CheckStyle，Findbugs等等代码规则检测工具检测出潜在的bug
糟糕的设计	找出循环，展示包与包、类与类之间的相互依赖关系，检测自定义的架构规则

三、 Sonar的优势

  Sonar的分析器在分析源码的时候，提供了技术债务、代码覆盖率、代码复杂度、已检测到的问题等。检查结果和其他静态代码检测工具是类似的，除了可以检测出bug外，还会包括可能的bug，可能引起bug的问题等等。简单总结Sonar的优点：

1. 支持多种源码检测：
  Sonar支持多种语言的检测，包括J ava、Python、Groovy、C、C++、JS等几十种编程语言的检测。
2. 报告格式清晰统一：
  Sonar在对检查结果进行分析后，会输出一个统一格式的分析结果，我们可以借助这一点实现多种编程语言的检查结果的统一化（我们目前Android、IOS、RN使用的不同检查工具的检查结果形式都是不同的）。
  Sonar检查结果会展示在一个动态的页面，通过不同的高亮方式标记不同的文件，清晰明显的标记告知查看者检查结果。而且在这个动态页面，还可以容易准确的查看项目的历史检测详情，便于对比。用图表和可视化的形式随着时间跟踪项目质量，还可以针对某个精确的时间放大分析结果，做更多的粒度分析。
3. 代码内可自定义规则：
  如果我们需要在Sonar上直接进行静态代码检查，也是可以增加自定义检查规则的，而Sonar的检查结果，自然也会将自定义的检查结果一同进行分析，实现更加定制化的代码质量管理。
Sonar在标准设定后，会强制性进行代码检测，代码必须通过所有检查项的检查。
4. 支持本地检测：
  SonarQube平台以源码作为输入。源码可以从IDE输入或者从SCM中提取。对于大多数流行的IDE，都有相应的SonarQube插件，使代码分析能够更加容易地在IDE中执行。
  开发可以直接在本地分支进行配置，直接“拉请求”，在当前开发分支上进行代码检测，而不必须把代码push到SonarQube上，这样缩短了反馈循环的时间，可以更好的提高代码效率（当然，目前我们的rn静态代码检查也可以在开发merge代码时检测，后续会继续学习二者是否有所不同）。

四、 实现成本

  无论是哪种形式或者哪种工具，静态代码检查都可以分为两个部分，一个部分是代码检测，一个部分是检查结果整理和分析。

1. 检查报告格式统一：
  目前我们已经在Jenkins上集成实现静态代码检查机制，也可以直接输出检查结果，所以可以考虑借助Jenkins上的sonar插件，将Jenkins和sonar联系起来，将我们在Jenkins上的检查结果在sonar上进行分析整理。
这样可以保证Android、Ios、RN的静态代码检查报告格式统一，在借入RD的App监测平台的时候，对于数据的处理更加方便。
2. Sonar引入SonarJS插件：
  SonarJS插件，顾名思义是JS静态代码检查的插件，SonarJS有自己的高稳定性质量标准，可以用在Eclipse and IntelliJ这些IDE上使用本地或者远程的SonarQube进行自动代码检查。但是需要注意的是，SonarJS自定义规则需要使用Java。目前我们使用的RN静态代码检查规则是使用Python自定义的，而且目前我们使用的IDE也都不是Eclipse and IntelliJ，所以后期如果进行检测迁移，还需要再深入调查来评估。
SonarJS支持以下几个框架和语言：

• ECMAScript 5 / ECMAScript 2015/ ECMAScript 2016 / ECMAScript 2017
• React JSX
• Vue.js
• Flow

  ESLint的检测其实是针对ECMAScript语言，使用 parserOptions 属性进行指定想要支持的 JavaScript 语言选项来实现的，所以直接使用sonarJS也可以实现JS和RN的静态代码检查的。
3. 在Sonar上实现JS或RN静态代码检查：
  如果不希望sonar只做检查结果分析，而是想在sonar上完成代码检测到结果分析整个流程，那么可以直接在sonar服务上添加插件，直接让sonar对源代码进行扫描即可；根据已经有的文档记录，sonar可以支持oclint、findbugs和eslint插件的集成。在sonar上接入持续集成，sonar对大量集成工具都提供了接口支持，所以sonar支持持续集成的。
  强制性质量标准制定后，源代码就必须要通过所有检查项，所以如果在定制化检查项的过程中，考虑到某些检查项不适合需要修改，就需要在sonar的源码中进行修改更新，来避开通用的强制检查项。
4. 集成机制的选择：
  Sonar如果想实现持续集成，内部依赖SonarScanner，但是也可以选择Jenkins或者Gitlab平台。