前言：code review：

        随着业务的发展，系统越来越庞大，原本简单稳定的功能，可能在不断迭代后复杂度上升，潜在的风险也随之暴露，导致最终服务不稳定，造成业务价值的损失。而为了减少这种情况，有一种比较好的方式就是提高代码质量，比如通过 code review，从而降低错误风险。首先，我们先来看看 code reivew 的用处：

• （1）code review 可以通过大家的建议改善代码的质量，提高代码的可读性、可维护性，以及确保程序逻辑和对需求、设计的实现的正确性
• （2）code review 是一个传递知识的方式，让不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码
• （3）code review 也鼓励程序员们相互学习对方的长处和优点
• （4）code review 也可以被用来确认自己的设计和实现是一个清楚和简单的

但在 code reivew 的诸多用处中，我们并没有提到可以帮助找到程序的bug和保证代码风格和编码规范，这是因为我们认为：

• code review 不应该承担发现代码错误的职责。code review 主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试，功能测试，性能测试，回归测试来保证。
• code review 不应该成为保证代码风格和编码规范的手段。编码规范和代码风格都属于死的东西，当把自己的代码提交给团队 review 时，代码就应该是符合规范的，这是属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。

        当然，上述言论只是说上面两件事情并不是 code review 的意图，并不是说，你不能在 code review 中报告一个程序的bug或是一个代码规范的问题。如果要把上述两件事归入 code review 的职责，那将会导致 code review 增加大量的人力成本，且工作量随代码量的增加而增加，审查效率低；并且简单的 code review 只能解决代码风格问题，很难发现代码缺陷、漏洞、重复度、复杂度等方面的问题，效果差。

        所以，对于上面这两件事情，除了需要作者自己保证外，当然还有工具可以帮助我们检查代码规范的，比如下文介绍的 Sonarqube 平台。

一、SonarQube 整体介绍：

1、SonarQube 是什么：

        SonarQube 是一个代码质量管理的开源平台，通过 SonarQube 提供的代码扫描、质量阈值卡点等质量红线，我们可以提升系统的可靠性，提前捕获和提示代码中的错误，从而避免未定义的行为影响到用户，保证业务质量，也能确保管理的代码库干净并且可维护，以便提高开发人员的开发效率。

        SonarQube 可以从以下七个维度检测代码质量，而作为开发人员至少需要处理前5种代码质量问题。

• （1）不遵循代码标准：sonar 可以通过 PMD、CheckStyle、Findbugs 等知名的静态代码规则分析工具规范代码编写。
• （2）潜在的缺陷：sonar 可以通过 PMD、CheckStyle、Findbugs 等知名的静态代码规则分析工具检测出潜在的缺陷。
• （3）糟糕的复杂度分布：文件、类、方法等，如果复杂度过高将难以改变，这会使得开发人员难以理解它们，且如果没有自动化的单元测试，对于程序中的任何组件的改变都将可能导致需要全面的回归测试。
• （4）重复：显然程序中包含大量复制粘贴的代码是质量低下的，sonar 可以展示源码中重复严重的地方。
• （5）注释不足或者过多：没有注释将使代码可读性变差，特别是当不可避免地出现人员变动时，程序的可读性将大幅下降，而过多的注释又会使得开发人员将精力过多地花费在阅读注释上，亦违背初衷。
• （6）缺乏单元测试：sonar可以很方便地统计并展示单元测试覆盖率。
• （7）糟糕的设计：通过sonar可以找出循环，展示包与包、类与类之间的相互依赖关系，可以检测自定义的架构规则，通过sonar可以管理第三方的jar包，可以利用LCOM4检测单个任务规则的应用情况，检测耦合。

        另外 SonarQube 也可以生成详细的代码分析质量报告，并通过强大的仪表盘展示出来，使我们能够根据角色的不同，查看不同维度的度量标准。

2、SonarQube 的工作原理：

官方给出了典型的开发过程：

• （1）开发人员在编写并提交代码（最好在 IDE 中集成 sonarlint 插件，并在本地进行代码分析检测，减少更多的缺陷代码被集成到 SCM 上）
• （2）SCM 通过 webhook 调用，触发 CI 持续集成，CI 触发 Sonar Scanner，将本地代码进行扫描分析，输出分析报告，并发送给 SonarQube 服务端
• （3）SonarQube 接受分析报告并处理，最终渲染到UI界面

SonarQube工作流程包含3个组件：

• （1）Scanner：扫描器，负责将源文件进行代码分析，并将分析后的报告发送给SonarQube服务器
• （2）SonarQube Server：SonarQube服务器，负责处理分析报告，后台管理等
• （3）Database server：数据库服务器，负责存储数据

三、SonarQube 功能与使用说明：

1、项目：

1.1、项目-总览：

1.2、项目-问题：

 问题共分为三种类型：

• Bug：潜在的代码缺陷，可能引起系统执行异常（比如空指针、魔法值等）
• 漏洞：潜在的安全漏洞，比如sql注入、cors、xss攻击等
• 异味：代码的坏味道。比如不遵循代码标准、糟糕的复杂度分布、注释不足或注释过多、糟糕的设计等

（1）问题类型（不推荐修改）

（2）问题的重要程度（不推荐修改）

（3）问题状态，分为五个状态：

• 打开：问题被质量分析后的初始状态（SonarQube）
• 确认：问题修复后，需要开发人员手动指定，表示该问题已修复（开发人员）
• 误判：标记问题为误判，表示此问题不应该标记为问题，无需处理（管理员）
• 标记为不会修复：表示此问题不做处理（管理员）
• 重新打开：当SonarQube再次分析报告时，若问题再次暴露则显示为重新打开（SonarQube）

（4）问题指派：

可以将问题分配给指定用户。

当问题分配给其他用户后，若该用户有启动提醒功能，则SonarQube会发送邮件进行告警

当 Sonar 分析报告后，会根据SCM的相关记录找到对应的用户，进行自动指派。

 （5）其他：

1.3、项目-安全热点：

安全热点是SonarQube检测出来可能存在安全问题，需要项目管理员进行复审，确认是否存在问题。

1.3.1、项目-安全热点-复审：

首先确保当前用户具有管理安全热点的权限

具有安全热点管理权限后，按钮将显示为蓝色

 复审状态总共有三个，分别为

• （1）需要复审：默认状态
• （2）已修复：表示该安全代码已经修复
• （3）安全：代码风险，无需修改

1.3.2、项目-安全热点-SonarQube提醒/建议：

在这个板块，SonarQube会解释为何是安全代码，且告诉你怎么修复。（英语不好的人建议翻译一下）

 翻译后

1.4、项目-指标：

观测当前项目的代码质量

1.5、项目-代码：

即SCM更新下来的代码，没啥区别，SonarQube自己也会存储一份

1.6、项目-活动：

分析记录的日志

 1.7、项目-项目配置：

管理项目的基本配置

1.7.1、设置：

设置项目的基本配置信息（不推荐）

1.7.2、新代码周期：

设置新代码周期的定义，默认按通用配置（即按上个版本的分析开始计算）。

也可以指定其他选项，如“天数”，可以指定距离上次分析多少天的数据作为为新代码

1.7.3、质量配置：

        质量配置，表示项目适配的质量配置，质量配置都是基于语言的，一个质量配置下面会存在多个代码规则。下图表示的项目qx_whale的质量配置基于java、xml两种语言，别分启用了452和11条代码规则。

1.7.4、质量阈：

它是项目质量是否合格的标准，通过设置质量阈来判断项目的代码质量是否达标。

 默认使用SonarQube内置的质量阈配置（Sonar way）

也可以自定义质量阈，如笔者定义的My Sonar Way，只要出现阻断违规问题，就达不到质量阈的要求

1.7.5、自定义指标：

即项目-指标板块，展示项目的代码质量。 官方表示未来会废弃，所以不推荐大家使用

1.7.6、链接：

配置一些跳转链接，比如项目的首页地址。建议在SonarScanner运行时指定sonar.links.homepage去配置首页地址

1.7.7、权限：

当前项目的权限配置，后面用户与权限模块会特别介绍，这里就不赘述了

1.7.8、后台任务：

可以查看项目最近分析的记录

1.7.9、更新标识：

SonarQube每个项目的标识都是唯一的，请确保使用者的项目标识唯一！！！

1.7.10、网络调用：

俗称web hook，懂得都懂（可以与jenkins集成，将分析报告的质量阈状态回传，以便jenkins判断是否继续执行pipeline任务）

1.7.11、删除：

谨慎操作，点击删除后有二次确认操作。

2、问题：

        问题菜单跟“项目-问题”展示的基本一致，不同的是，问题菜单展示的是个人参与项目的所有问题，所以数量上相对较多

3、代码规则：

代码规则，用来分析代码是否有问题

4、质量配置：

质量配置，用于定义编程语言的代码分析集合。一个质量配置可以配置多个代码规则

举个例子，我们看下质量配置/Java下的代码规则详情，下图表示Java语言的质量配置模板Sonar way，共配置了452个激活的规则，187个未激活的规则，一共配置了639个规则。

内置质量模板Sonar way不允许修改，若用户想要自定义质量模板，必须拥有“质量配置管理员”的权限才可以进行操作。

举个例子，新建一个Java语言的质量模板

在左边的卡片“规则”中，我们点击“更多激活规则”

回到质量模板MyJavaRule，可以看到我们配置了一条代码规则。那么质量配置就介绍到这里了。

什么情况下会使用到质量配置呢？一般使用官方内置的Sonar way即可，如果有特殊需求的话，可以自己去定义质量模板。

5、质量阈：

        质量阈是一系列基于指标的布尔表达式，用户标准化质量，它可以帮助我们实时了解项目是否已经满足生产要求了。在集成进流水线的情况下，质量阈提供了质量卡点的能力，当存在质量项尚未达标的情况下，阻止发布流程进入到下一环节，流水线运行时会根据对应的质量红线对测试任务进行判断，是否能够通过红线，如果未通过红线，对应的任务将失败。但考虑在一些特殊的情况下，未通过质量红线的流程也需要继续往下执行，可以由管理员将红线跳过

上图表示，所有项目默认的质量阈均为Sonar way，指标解释：新代码分析时，若覆盖率小于80% 或者 重复行大于3% 或者…安全比率劣于A时，判定为质量阈失败。

5.1、质量阈-自定义质量阈：

        默认情况下，所有项目使用相同的质量阈，每个项目的质量阈状态都会展示在首页。质量阈值也可以进行自定义，设定不同等级的阈值，对于老项目，会使用最低等级的阈值：阻断性的错误数量要求为0，对于一些新的项目，则严格要求质量如严重性的错误要求为0等，只要无法通过质量阈值检查，那么项目是无法上线的。

        自定义质量阈，首先要有质量阈管理员的权限，可以参考下图设置（建议技术经理或者项目负责人设置此权限）

新建一个自定义质量阈MySonarWay，只添加一个条件，当阻断违规的问题大于0时，判定为质量阈失败。

同时，还可以指定哪些项目使用此质量阈

6、配置： 

6.1、用户与权限：

6.1.1、用户管理：

 6.1.2、群组管理：

可以通过群组，来进行用户的统一授权

 6.2、项目权限：

项目权限，用于设置公开或者私有，公开项目所有人都可以访问，私有项目只有访问权限的人可以访问（推荐）

设置项目权限范围，管理员等

6.3、用户与权限-最佳实践：

6.3.1、最佳实践-角色分工：

角色大致上可以分为三种：系统管理员、技术经理、开发人员

（1）最佳实践-角色分工-系统管理员：

系统管理员：只负责sonar平台的管理，不负责项目相关操作

（2）最佳实践-角色分工-技术经理：

技术经理：负责项目成员定义，项目组定义，权限分配，质量配置、质量阈等配置

 （3）最佳实践-角色分工-开发人员：

开发人员：默认项目创建与项目执行分析，当开发人员创建项目时，该人员成为项目的管理者，拥有项目的所有权

（4）最佳实践-权限模板：

配置默认权限模板（Default template），项目创建人拥有项目的所有权。

 若技术经理也需要同等权力的话，可以主动申请成为项目的管理员(详见下图)

 6.4、提醒（邮件告警）

6.4.1、系统邮件设置：

 6.4.2、项目提醒设置：

只有订阅了项目提醒，用户才会收到项目推送的邮件。在管理员进行问题分配给用户时，特别有用。以下介绍如何进行项目提醒设置：

（1）方式一：

进入项目

点击项目信息，设置提醒

 全部勾选

（2）方式二（推荐）：

一步到位，设置也简单。在个人账号设置自己的 

1、主要参考文章：

https://blog.csdn.net/weixin_31257709/article/details/124566064

2、推荐阅读：

从Code Review 谈如何做技术

Code Review中的几个提示