最近需要准备将不同平台的静态代码检查集成到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平台。
