Sonar代码质量检测相关知识及推广步骤梳理

Sonar代码质量检测相关知识及推广

背景介绍

一、什么是代码质量：

代码质量指的是代码内在的非功能性的质量，用户不能直接体验到这种质量的好坏，代码质量不好，最直接的”受害者“是开发者或组织本身，因为代码质量好坏直接决定了服务本身得到可维护性成本的高低。

《Sonar code quality testing essential》一书中从七个维度定义了代码质量，具体维度内容如下：

1. 编码规范：是否遵守了编码规范，遵循了最佳实践。
2. 潜在的BUG：可能在最坏情况下出现问题的代码，以及存在安全漏洞的代码。
3. 文档和注释：过少（缺少必要的信息）、过多（没有必要的的信息）、过时的文档或注释。
4. 重复代码：违反了Don`t Repeat Yourself原则。
5. 复杂度：代码结构太复杂（如复杂度高），难以理解、测试和维护。
6. 测试覆盖率：编写单元测试，特别是针对复杂代码的测试覆盖率是否足够。
7. 设计与架构：是否高内聚、低耦合

二、我们可以从可测性，可读性，可理解性，容变性等代码可维护维度的质量属性来衡量代码质量。下面，我举例几个代码质量有待提高的例子

1. 重复代码会造成维护成本的成倍增加；
2. 不规范的代码、不良的注释和复杂度过高的代码会增加阅读和理解代码的难度；
3. 复杂度过高也会极大的增加测试覆盖的难度，耗费过多人力；
4. 缺少测试覆盖的代码会使得定位问题和修复问题的难度加大；
5. 结构不良、低内聚高耦合的代码则会使得哪怕是微小的需求变更或功能扩展都无从下手，修改的代价很可能超过了重写的代价。

三、针对代码质量暴露出来的一些问题，我们可以做哪些事情，由此引出我们的代码质量检测

在我们想通过什么方法来鉴定代码质量时，我们还是难以回答某段代码有多好或多差，两段代码相比哪个更好这样的问题，因为我们仍然没有完全解决代码质量的量化问题；

比如说：

1. 同样都是代码质量问题，重复代码和过多注释的危害肯定是不一样的；
2. 同样都是方法太复杂，圈复杂度为10的方法和圈复杂度为20的方法相比，危害和修改难度也差别很大。

综上：所以我们不能直接用问题的数量来衡量质量，需要找到更精细合理的量化度量方法。

Sonar介绍

一、什么是Sonar：

Sonar 是一个用于代码质量管理的开放平台。通过插件机制，Sonar可以集成不同的测试工具，代码分析工具，以及持续集成工具。与持续集成工具（例如 Hudson/Jenkins 等）不同，Sonar 并不是简单地把不同的代码检查工具结果（例如 FindBugs，PMD 等）直接显示在 Web 页面上，而是通过不同的插件对这些结果进行再加工处理，通过量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的工程进行代码质量管理。

二、Sonar代码检测的优点

1. 在对其他工具的支持方面，Sonar 不仅提供了对 IDE 的支持，可以在Eclipse和Vs Code这些工具里集成代码质量检测。
2. Sonar 还对大量的持续集成工具提供了接口支持，可以很方便地在持续集成中使用 Sonar。
3. Sonar 的插件还可以对 JavaScript 以外的其他编程语言提供支持，对国际化以及报告文档化也有良好的支持。

三、Sonar代码检测系统的四个组成部分

1. sonarQube服务器 包含三个子进程（web服务（界面管理），搜索服务 计算引擎服务（写入数据库））。
2. PostgreSQL数据库提供存储功能。
3. 灵活的插件配置。
4. 多种sonarqube scanners 分析工具。

四、Sonar代码检测的工作流程

1. 开发者使用开发工具（eclipse,idea,vs-code）上传代码到SCM(源代码管理器)。
2. 触发系统自动同步代码到某个位置 ，用sonarqube scanners 扫描该代码检查质量，得到分析结果。
3. 将分析结果推送到sonarqube Server 存储在DB数据库。
4. 用户可以使用vs-code插件sonarlint来同步sonarqube服务器配置（js和java版本等）可以实时在线分析。

如何在公司业务中推广Sonar代码检测（持续更新，同时也希望的到大佬更多的建议）

第一步：Sonar环境搭建

1. 首先要有Sonar代码检测的环境，需要一套部署好的Sonar服务
2. 在公司devops过程中，部署阶段前可以触发Sonar代码检测，并可以根据代码检测做一些事情。

第二步：有了Sonar的环境，咱们就可以说说如何使用

1. 在SonarWeb端，创建令牌，并创建好待检测的项目。此时可以尝试Sonar本地扫描，观察是否数据能够正常同步到Sonarweb端。
2. 指定属于自己业务的Sonar代码检测规则，这一步其实最需要注意的，在指定规则时，需要同业务、leader对齐，同时约定好，在Sonar代码检测出问题时，将采取何种态度、措施解决问题，这将对推广产生至关重要的影响。
3. 结果同步，推动过程中，需要实时记录状态，并根据实际项目推广修改过程中，反复checkSonar代码检测规则的合理性。
4. 在迭代中，不断完善Sonar代码规则，及一些必要的全局配置（如环境变量、排除检测第三方库的等等）

第三步：总结及复盘

推广不易，要把握住每一次机会，也就是check自己做的事情，哪些地方做的额不好，还可以在哪些方面优化，以后其他人遇到有什么解决方法让后面遇到的人少采坑，这些是我记录此文章的初衷。希望对大家有所帮助！