document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-23 21:20:42 +08:00
Code Issues Packages Projects Releases Wiki Activity

[Translated] 20171027 Scout out code problems with SonarQube.md

Browse Source
This commit is contained in:
Jamkr 2018-11-10 08:55:17 +08:00
parent 54bd9b172c
commit c23486d67c
2 changed files with 63 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
sources/tech/20171027 Scout out code problems with SonarQube.md
View File

@ -1,67 +0,0 @@
Translating by Jamkr
Scout out code problems with SonarQube
======
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/open%20source_collaboration_0.png?itok=YEl_GXbv)
More and more organizations are implementing [DevOps][1] to make it faster to get quality code into the production environment after passing through the intermediate development and testing environments. Although things such as version control, continuous integration and deployment, and automated testing all fall under the scope of DevOps, one critical question remains: How can an organization quantify code quality, not just deployment speed?
[SonarQube][2] is one option to fill this gap. It is an open source platform that continually inspects code quality via automatic static analysis of the source code. SonarQube can analyze more than 20 coding languages and store issues on all sorts of project types.
SonarQube also offers a centralized location for maintaining and managing code issues within multiple, multi-language projects simultaneously. Custom rules can be implemented per project. Continuous inspection permits the analysis of the overall trajectory of the code's health.
SonarQube can also be integrated into continuous integration and development (CI/CD) pipelines, assisting in and automating the process of determining the code's readiness for the production environment.
### What it can measure
Out of the box, SonarQube can measure key metrics, including bugs, code smells, security vulnerabilities, and duplicated code.
* **Bugs** are portions of code that are incorrect or likely functioning improperly, thus producing potentially erroneous results. These are obvious errors that should be fixed before the code is released to production.
* **[Code smells][3]** differ from bugs in that the detected code likely functions correctly and as intended. However, it may be hard to maintain, lead to future bugs, be uncovered by unit tests, or have other problems. For long-term maintainability, it's smart to fix code smells right away. It's generally hard to detect code smells when writing code, but SonarQube's static analysis is one way to discover them.
* **Security vulnerabilities** are exactly as they sound: a flaw somewhere in the code that may present a security issue. These vulnerabilities should be fixed to prevent hackers from exploiting them.
* **Duplicated code** is also exactly as it sounds: portions of code that are repeated in the source code. Code duplication is a bad practice in software design. On the whole, it leads to maintainability problems if changes are made to one portion but not another. Identifying code duplication makes it easier to package the duplicated code into a library for repeated use, for example.
### What customization options exist
Because it is open source, SonarQube encourages users to develop and offer customization options. Currently there are more than 60 [plugins][4] available to augment SonarQube's out-of-the-box analysis functionality.
The majority of the plugins were created to increase the number of coding languages SonarQube can analyze. Other plugins enable analysis of extra metrics or include other views for the displayed dashboards. Essentially, if an organization needs to examine a custom metric, wants to view its analyzed data in specific ways on its own dashboard, or uses a coding language that SonarQube doesn't support, there are probably customization options available. If the needed functionality doesn't yet exist, the openness of SonarQube's source code makes it possible to develop custom solutions.
Users can also customize the rules applied for each specific coding language analyzer. Rules can be selected and deselected per language and per project through SonarQube's user interface. These options recognize the need for project-specific rules, as well as maintaining all data and configurations in a central location.
### Why it's important
SonarQube provides a centralized location for organizations to manage and track issues in their code throughout multiple projects. It also allows continuous inspection combined with a quality gate. Once a project has been analyzed, further analyses update the original statistics, as the software is modified, to reflect the latest changes. This tracking allows users to view how well and how quickly code issues are being resolved, consistent with a "release early and release often" mentality.
Additionally, SonarQube can be utilized in a [continuous integration pipeline][5], such as those run on tools like [Hudson][6] and [Jenkins][7]. The quality gate will reflect the overall health of the code and, by integrating with tools like Jenkins, can play an important role in deciding when to release code to the production environment.
In the spirit of DevOps, SonarQube can quantify code quality to help organizations meet internal requirements. In order to speed the cycle of code production and release, organizations must be aware of their technical debt and software issues. By uncovering this information, SonarQube can help organizations more rapidly produce the highest quality software possible.
### Want to learn more?
SonarQube is licensed under the GNU Lesser General Public License, and its source code is available on [GitHub][8]. There is a growing community of users interested in SonarQube, its features, and its capabilities. There are active communities on [Twitter][9] and [Google][10]; these as well as the [SonarQube blog][11] are helpful for anyone interested in getting started with SonarQube.
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/10/sonarqube
作者：[Sophie Polson][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/sophiepolson
[1]:https://en.wikipedia.org/wiki/DevOps
[2]:https://www.sonarqube.org/
[3]:https://en.wikipedia.org/wiki/Code_smell
[4]:https://docs.sonarqube.org/display/PLUG/Plugin+Library
[5]:https://jenkins.io/blog/2017/04/18/continuousdelivery-devops-sonarqube/
[6]:https://en.wikipedia.org/wiki/Hudson_(software)
[7]:https://en.wikipedia.org/wiki/Jenkins_(software)
[8]:https://github.com/SonarSource/sonarqube
[9]:https://twitter.com/SonarQube
[10]:https://groups.google.com/forum/#!forum/sonarqube
[11]:https://blog.sonarsource.com/

63
translated/tech/20171027 Scout out code problems with SonarQube.md Normal file
View File

@ -0,0 +1,63 @@
使用 `SonarQube` 追踪代码问题
======
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/open%20source_collaboration_0.png?itok=YEl_GXbv)
越来越多的组织正在实施 [DevOps][1] 以便在通过中间开发和测试环境以后更快更好的将新代码引入到生产环境。虽然版本控制，持续集成和部署以及自动化测试都属于 `DevOps` 的范畴，但仍然存在一个关键问题：组织如何量化代码质量，而不仅仅是部署的速度？
[SonarQube][2] 是用来填补这个空隙的一种选择。它是一个开源平台，通过自动化静态分析不断的检查代码质量。 `SonarQube` 支持 20 多种语言的分析，并在各种类型的项目中输出和存储问题。
`SonarQube` 同时也提供了一个可同时维护和管理不同项目，不同代码的集中的环境。可以为每个项目定制规则。持续的检查和分析代码健康轨迹。
`SonarQube` 还可以集成到可持续集成和开发 (`CI/CD`) 流程中，协助和自动化确定代码为生产做准备和过程。
### 它可以衡量什么
开箱即用， `SonarQube` 可以测量的关键指标，包括代码错误 (`bugs`)，代码异味 (`code smells`)，安全漏洞 (`security vulnerabilities`) 和重复性的代码 (`duplicated code`)。
* **代码错误** 是指那些在代码发布到生产环境之前应该被修复的明显的错误。
* **[代码异味][3]** 不同于代码错误，它检测的是代码正确正确执行的过程和可能的预期。然而，它不容易被修复，也不能被单元测试覆盖，却可能会导致一些未知的错误，或是一些其它的问题。从长期的可维护性来讲，立即修复代码异味是明智之举。通常在编写代码的时候，代码异味并不容易被发现，而 `SonarQube` 的静态分析是一种发现它们的很好的方式。
* **代码漏洞** 正如听起来的一样：指的是现在的代码中可能存在的安全问题的缺陷。这些缺陷应该立即修复来防止黑客利用它们。
* **重复的代码** 也和听起来的一样：指的是源代码中重复的部分。代码重复在软件设计中是一种很不好的做法。总的来说，如果对一部分代码进行更改而另一部分没有，则会导致一些维护性的问题。例如，识别重复的代码可以很容易的将重复的代码打包成一个库来重复的使用。
### 可自定义的选项
因为它是开源的，所以 `SonarQube` 鼓励用户开发和提供可定制的选项。目前有超过 60 个[插件][4] 可用于增强 `SonarQube` 开箱即用的分析功能。
大多数的插件是为了增加 `SonarQube` 可以分析的编程语言的数量。另一些插件可以分析一些额外的指标甚至包括仪表盘的一些显示的视图。实际上，如果组织需要松果一些额外的自定义的指标，或是想要在自己的仪表盘和以特定的方式查看分析数据，或使用 `SonarQube` 不支持的编程语言，则可能存在一些自定义的选项可以使用。如果你想要的功能并不支持， `SonarQube` 开放的源码也为你自己开发新的功能提供了可能性。
用户还可以定制适用于每种特定编程语言分析器的规则。通过 `SonarQube` 用户界面，按每种语言和每个项目选择和取消规则。这些为特定的项目指定的规则，可以很好的在一个集中的位置维护所有的数据和配置。
### 为什么它那么重要
`SonarQube` 为组织提供了一个集中的位置来管理和跟踪多个项目代码中的问题。它还可以把持检查和质量门成相结合。一旦项目分析过一次以后，更进一步的分析会参考软件最新的修改来更新原始的统计信息。这些跟踪可以让用户看到问题解决的程度和速度。这与 “早发布并常发布”（`release early and release often`）不谋而合。
另外，`SonarQube` 可使用 [可持续集成的管道][5]，比如像 [Hudson][6] 和 [Jenkins][7] 这样的工具。这个质量门可以很好的反映代码的整体运行状况，并且通过 `Jenkins` 等集成工具，在发布代码到生产环境的担任一个重要的角色。
本着 `DevOps` 的精神， `SonarQube` 可以量化代码质量，来达到组织内部的要求。为了加快代码生产和发布的周期，组织必须意识到它们自己的技术债务和软件问题。通过发现这些信息， `SonarQube` 可以帮助组织更快的生成高质量的软件。
### 想要了解更多吗？
`SonarQube` 基于 `GUN` 通用公共许可证发布，它的源码可以在 [GitHub][8] 上查看。越来越多的用户对 `SonarQube` 的特性和功能感兴趣。 [Twitter][9] 和 [Google][10] 上有活跃的社区。这些社区以及 [SonarQube 博客][11] 对任何有兴趣开始和使用 `SonarQube` 的人有很有帮助。
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/10/sonarqube
作者：[Sophie Polson][a]
译者：[Jamkr](https://github.com/Jamkr)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/sophiepolson
[1]:https://en.wikipedia.org/wiki/DevOps
[2]:https://www.sonarqube.org/
[3]:https://en.wikipedia.org/wiki/Code_smell
[4]:https://docs.sonarqube.org/display/PLUG/Plugin+Library
[5]:https://jenkins.io/blog/2017/04/18/continuousdelivery-devops-sonarqube/
[6]:https://en.wikipedia.org/wiki/Hudson_(software)
[7]:https://en.wikipedia.org/wiki/Jenkins_(software)
[8]:https://github.com/SonarSource/sonarqube
[9]:https://twitter.com/SonarQube
[10]:https://groups.google.com/forum/#!forum/sonarqube
[11]:https://blog.sonarsource.com/