SonarQube价格、代理商，正版购买--青穗软件

Refactor thi*ethod to reduce its Cognitive Complexity from 17 to the 15 allowed

重构此方法以将其认知复杂度从17降低到15

 

Remove this assignme*f "dataSource".

 

Rename this field "format_insert_error" to match the regular expression '^[a-z][a-zA-Z0-9]*$'.

 

 

Remove this expression which always evaluates to "true"

删除该表达式，该表达式总是求值为“true”。

 

Merge this if statement with the enclosing one.

将此if语句与封闭语句合并。

 

Invoke method(s) only conditionally.

仅条件地调用方法。

 

Add a private c*tructor to hide the implicit public one.

添加一个私有构造函数来隐藏隐含的公共构造函数

 

Format specifiers should be used instead of string concatenation.

应该使用格式说明符来代替字符串连接。

 

Replace the type specification in thi**tructor call with the diamond operator ("<>").

用菱形运算符（“< >”）替换此构造函数调用中的类型规范。

 

Extract this nested try block i* a separate method.

将这个嵌套的试块提取成一个单独的方法。

 

Remove this redundant jump.

删除此冗余跳转。

 

Replace this lambda with a method reference.

用方法引用替换这个lambda。

 

Define a c*tant instead of duplicating this literal "SendBatchNo" 3 times.

定义一个常量，而不是*这个字面“StBaBeNeNo”3次。

 

Rename field "SENDBATCHNO" to prevent any misunderstanding/clash with field "sendBatchNo&quo*fined on line 22

重命名字段“SENDBATCHNO”以与第22行定义的字段“sendBatchNo”发生任何误解/冲突

 

Replace this if-then-else statement by a single return statement.

用一个返回语句替换这个IF THEAR语句。

 

Either re-interrupt thi*ethod or rethrow the "InterruptedException".

 

 

Use "j*a.nio.Files#delete" here for better messages on error conditi*.

 

Use isEmpty() to check whether the collection is empty or not.

 

A "NullPointerException" could be thrown; "columns" is nullable here.

 

Reduce the total number of break and continue statements in this loop to use at most one.

在这个循环中减少break和continue语句的总数，多使用一个。

 

Merge this if statement with the enclosing one.

将该if语句与附带的if语句合并。

 

Remove useles*urly braces around statement

删除语句周围无用的花括号

 

Lower the visibility of this setter or remove it altogether.

降低此setter的可见性或将其完全删除。

 

Make this final field static too.

 

Remove the "connector" field and declare it as a local variable in the relevant methods.

 

Immediately return this expression instead of assigning it to the temporary variable "ss".

立即返回此表达式，而不是将其分配给临时变量“ss”。

 

Use isEmpty() to check whether the collection is empty or not.

使用isEmpty（）检查集合是否为空。

 

Use*ariable binding mechani* to c*truct this query instead of concatenation.

使用变量绑定机制来构造此查询，而不是连接

 

String sql = "select column_name from user_col_comments where table_name='" + tableName + "'";

修改成

String sql = "select column_name from user_col_comments where table_name=?";

pstm = conn.prepareStatement(sql);

pstm.setString(1, tableName);

Remove this hard-coded password.

移除代码里硬编码的密码信息。

Remove this hard-coded path-delimiter.

删除此硬编码路径分隔符。

Remove useles*urly braces around statement and then remove useless return keyword

移除语句周围无用的花括号，然后移除无用的返回

不符合代码示例

x -> {System.out.println(x+1);}

(a, b) -> { return a+b; }

解决方案

x -> System.out.println(x+1)

(a, b) -> a+b 

Reorder the modifiers to comply with the J*a Language Specification.

问题代码

public final static String BOOLEAN = "Boolean";

解决方案

public static final String BOOLEAN = "Boolean";

————————————————

版权声明：本文为CSDN博主「InJ*aWeTrust」的创文章，遵循  4.0 BY 版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn*/InJ*aWeTrust/article/details/101687889

 

哇，好多bug,漏洞，然后你就慢慢有针对性的检查自己的代码吧。

 

总结：代码有bug是在所难免的，但是我们作为开发人员是可以避免出现部分bug的，这就要求我们规范自己的代码习惯，思考发现的问题，及时改进，保证下次写代码不会再犯，做到努力自己的代码质量，追求代码的。

 SonarQube

产品概述：

SonarQube是一个开源平台，用于管理源代码的质量。SonarQube不只是一个质量数据报告工具，更是代码质量管理平台。

SonarQube平台提供了许多功能，可帮助您进行持续检查进程取得成功。

产品特点：

一目了然

l  无论你是想在文件，模块，项目或组合层面来管理代码质量，SonarQube众多的仪表板为你提供快速的洞察力。看看Nemo，SonarQube我们的公共实例，看看会期望发生什么。

所有利益相关者

l  很多仪表板可开箱即用，并且新的仪表盘可能性是无止境的，你是否希望把*放在措施或问题。用户可以创建完全定制的*仪表盘，只显示有价值的数据给他们。

七宗罪

l  该平台涵盖了的7种维度，也被称为开发商“七宗罪：重复，编码标准，覆盖面不足，潜在的错误，复杂性，文档和设计。

单一职责原则

面向对象五大设计模式基本原则之一。即一部分代码只应该用于某一个特定功能，不应与其他功能耦合在一起。

假设你的一个function同时实现了功能a和功能b，之后需求变更，你需要修改功能a，但是因为这两个功能都在一个function里，你就不得不再去确认是否会影响到功能b。这就造成了不必要的成本。

如下我总结了三个拆分代码的原则：

“and”原则

当你为你的方法命名时不得不加上“and”时，就该考虑考虑是不是要把这个方法拆分一下了。

“100”原则

当你的一个function超过一百行时，一定要进行拆分了。

注：这里的100可能有点多，只是对我个人而言，100算是我的限，总之就是不要将一个函数写的太长。

命令、查询拆分原则

我们开发中大部分操作可以总结为“命令”和“查询”，如写cookie、修改data、发送*t请求都可以叫“命令”，而读取cookie、ajax获取数据则认为是“查询”操作。

函数式编程中讲究“数据不可变”，即：

只有纯的没有*的函数，才是合格的函数。

*：指当调用函数时，除了返回函数值之外，还对主调用函数产生附加的影响。例如修改全局变量（函数外的变量）或修改参数。

好处是使得开发更加简单，可回溯，测试友好，减少了任何可能的*。

将“命令”与“查询”拆分实际上就是函数式编程思想的部分体现，参考如下代码：

function getFirstName() {  var firstName = document.querySelector("#firstName").value;  firstName = firstName.toLowerCase();  setCookie("firstName", firstName);  if (firstName === null) {      return "";  }  return firstName;}var&nb*ctiveFirstName = getFirstName();

通过名字来看，该方法是用于获取first name的，但实际上它还设置了cookie，这是我们没有预料的。对于一个“查询”方法，它不应该有任何修改方法外变量的行为，即“*”。更好的写法如下：

function getFirstName() {  var firstName = document.querySelector("#firstName").value  if (firstName === null) {      return "";  }  return firstName;}setCookie("firstName", getFirstName().toLowerCase());

一目了然，getFirstName只返回firstName，而设置cookie操作在它之外进行。

易用性原则

简单

这里的简单，主要归结为function的一些设计原则，有如下几点：调用简单、易理解、减少记忆成本、参数处理。

如下，仅仅想实现修改dom颜色、宽度等属性，原生代码如下：

document.querySelector('#id').style.color = 'red'document.querySelector('#id').style.width = '123px'document.querySelector('#id').style.height = '456px'

而封装过后：

function&nb*(selector, color, width, height) {document.querySelector(selector).style.color = colordocument.querySelector(selector).style.width = widthdocument.querySelector(selector).style.height = height}a('#a', 'red')

瞬间变得简单可用了 ~

但该方法还存在一个问题，那就是命名太抽象了。。。除了*自己以外不可能有人在不看源码的情况下一眼看出这个方法a是干嘛的。那么咱再把这个方法名改写得更易理解一点：

function letSomeElementChange(selector, color, width, height) {document.querySelector(selector).style.color = colordocument.querySelector(selector).style.width = widthdocument.querySelector(selector).style.height = height}

这样我们就能一目了然该方法的作用 ~ 不过仍有可优化的地方。这么长的方法名谁记得住，要减少记忆成本啊，再改个名：

function setElement(selector, color, width, height) {document.querySelector(selector).style.color = colordocument.querySelector(selector).style.width = widthdocument.querySelector(selector).style.height = height}

OK，目前这个方法已经满足它的职责并且很好用了，但还觉得怪怪的。这一坨参数太碍眼。。。

function setElement(selector, opt) {c*t { color, width, height } = optcolor&nb*mp;& document.querySelector(selector).style.color = colorwidth&nb*mp;& document.querySelector(selector).style.width = widthheight&nb*mp;& document.querySelector(selector).style.height = height}

把多个参数合并一下，并在内部做兼容处理，这个方法便易用多了。即使不传第二个参数也不会有任何*。

一致性

假如有这样一个方法，获取歌曲列表，并将其设置到div的innerText中：

function getSongs() {return $.get('/songs).then((resp*e) {    div.innerText = resp*e.songs})}

这就违背了方法的表里一致性，也违背了上文的单一职责原则中命令、查询拆分原则，因为它不仅获取了歌单，同时还修改了innerText，要让其更合理：

低耦合

耦合是衡量一个程序单元对其他程序单元的依赖程度。耦合（或高耦合）是应该力避免的。如果你发现自己正在*和粘贴代码并进行小的更改，或者重写代码，因为其他地方发生了更改，这就是高耦合的体现。

耦合会严重影响代码的复用性及可扩展性，让后人维护时不得不修改甚至重写这部分代码，不仅浪费时间还会导致仓储中又多出一块类似的代码，很容易让人迷惑。

同时，修改耦合度高的代码时经常会牵一发而动全身，如果修改时没有理清这些耦合关系，那么带来的后果可能会是灾难性的，特别是对于需求变化较多以及多人协作开发维护的项目，修改一个地方会引起本来已经运行稳定的模块错误，严重时会导致*循环，问题永远改不完，开发和测试都在各种问题之间奔波劳累，后导致项目延期，用户满意度降低，成本也增加了，这对用户和开发商影响都是很恶劣的，各种风险也就不言而喻了。

高内聚

不应该将没有任何联系的东西堆到一起。

内聚是一个类中变量与方法连接强度的尺度。高内聚是值得要的，因为它意味着类可以更好地执行一项工作。低内聚是不好的，因为它表明类中的元素之间很少相关。每个方法也应该高内聚，大多数的方法只执行一个功能，不要在方法中添加‘额外’的指令，这样会导致方法执行更多的函数，同时也违反了上文的单一职责原则。

低内聚的体现：如果属性没有被类中的多个方法使用，这可能是低内聚的标志。同样，如果方法在几种不同的情况下不能被重用，或者如果一个方法根本不被使用，这也可能是低内聚的一个标志。

高内聚于高耦合，高耦合是需要高内聚的标志。但是，如果两个问题同时存在，应当选择内聚的方式。对于*来说，高内聚通常比低耦合更有帮助，尽管两者通常可以一起完成。

错误处理

• 可预见的错误：诸如ajax回调、函数参数，这类问题很好解决，只需在开发时多考虑一步，对各种端情况做好兼容即可。

• 不可预见的错误：类似兼容性问题，这类问题无法在开发时准确预见的错误，可以准备好抛错，c*ole.error/log/warn，后你还可以为自己的程序留些后路: try...catch。

可读性原则

命名

命名应该保证别人通过名称一眼就能知道这个变量保存的是什么，或者这个方法是用来做什么的。

普通变量、属性用名词如下：

var person = {  name: 'Frank'}var student = {  grade: 3,  class: 2}

bool变量、属性用（形容词）或者（be动词）或者（情态动词）或者（hasX），如下：

var person = {  dead: false, // 如果是形容词，前面就没必要加 is，比如isDead 就很废话  canSpeak: true, //情态动词有 can、should、will、need 等，情态动词后面接动词  isVip: true, // be 动词有 is、was 等，后面一般接名词  hasChildren: true, // has 加名词}

普通函数、方法用（动词）开头：

var person = {  run(){}, // 不及物动词  drinkWater(){}, // 及物动词  eat(foo){}, // 及物动词加参数（参数是名词）}

回调、钩子函数：

var person = {  beforeDie(){}, &nb*fterDie(){},  // 或者  willDie(){}  dead(){} // 这里跟 bool 冲突，你只要不同时暴露 bool dead 和函数 dead 就行，怕冲突就用上面的&nb*fterDie}button.addEventListener('click', onButtonClick)var component = {  beforeCreate(){},  created(){},  beforeMount(){}}

命名一致性

• 顺序一致性：比如 updateContainerWidth 和 updateHeightOfContainer 的顺序就令人很别扭

• 时间一致性：有可能随着代码的变迁，一个变量的含义已经不同于它一开始的含义了，这个时候你需要及时改掉这个变量的名字。

这一条是难做到的，因为写代码容易，改代码难。如果这个代码*得不好，很可能会出现牵一发而动全身的情况（如全局变量就很难改）

注释

不需要多花哨，只要把作用、用法描述清楚即可。方法的标准注释应该如下：

/*** [function_name de*ription]* @param  {[type]}&nb*rgument [de*ription]* @return {[type]}          [de*ription]*/function function_name(argument) {// body...}

将方法的参数与返回值都写清楚，我目前用的IDE是sublime，使用Docblockr插件可以自动生成格式化注释，很方便。

Bad Smell

项目中我们经常能够遇这类代码，它们仍可用，但是很“臭”，国外管这类代码有一个统称，即“bad *ell”。如下这类代码可以说是很“臭”了：

• 表里不一的代码

• 过时的注释

• 逻辑很简单，但是看起来很复杂的代码

• 重复的代码

• 相似的代码

• 总是一起出现的代码

• 未使用的依赖

• 不同风格的代码

样式规范

1. 正确命名：class必须用“-”写法，不要用驼峰和下划线。

2. 正确嵌套：正常情况下一定要将class嵌套闭合，否则就相当于添加到全局，如果有重复命名的class就会受影响。

3. 拒绝copy：如果想复用已有的样式，直接在原有class上用“,”语法分割，就能应用，不要再copy一份样式，会让两份样式都被应用，就要考虑样式覆盖的问题，很不友好。

4. 滥用class：没有必要加的class不要加，每个class的添加都应该有明确理由。滥用class的话可能会导致样式覆盖，不该应用这个样式的地方用了这个样式。

5. 慎用 !important，会强行覆盖所有同属性样式，一旦使用后会让代码难以维护，开发过程中不要依赖该方法。如下总结了一些使用 !important的经验：

• 一定要优化考虑使用样式规则的优先级来解决问题而不是 !important

• 只有在需要覆盖全站或外部 css（例如引用的 ExtJs 或者 YUI ）的特定页面中使用 !important

• 解决紧急线上问题可以使用，但之后也要尽快用可维护的方式将代码替换回来

• 永远不要在全站范围的 css 上使用 !important

• 永远不要在你的插件中使用 !important

说得容易，做起来难

*窗效应

此理论认为环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉。一幢有少许*窗的建筑为例，如果那些窗不被修理好，可能将会有*者*更多的窗户。终他们甚至会闯入建筑内，如果发现无人居住，也许就在那里定居或者纵火。一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西；一条人行道有些许纸屑，不久后就会有更多垃圾，终人们会视若理所当然地将垃圾顺手丢弃在地上。这个现象，就是犯罪心理学中的*窗效应，在编程领域同样存在。

要做到：只要是经过你手的代码，都会比之前好一点。

l  您正在寻找什么的，一个项目，一批项目，等等，你可以点击几下打*任何指标，并深入到信息的来源：源代码！

自动化

l  质量分析，可以很容易地集成到任何持续集成服务器到完全自动化的过程。这使您可以轻松持续地检查过程。

安全

l  认证和授权是一个是直接可用的完整机制，但它也可能安全委托给外部系统，如LDAP，活动目录等，或使用SSO。

扩展

l  扩展是DNA平台的一部分，可通过SonarQube插件库它可以扩展60多种插件。您也可以开发自己的插件。

集成

l  集成出来的标准ALM组件，如M*en， Ant， SVN，Git， Mercurial， JIRA， Mantis，Google Analytics，Piwik，Fortify等等

SonarQube 是一款用于代码质量管理的开源工具，它主要用于管理源代码的质量。 通过插件形式，可以支持众多计算机语言，比如 j*a, C#, go，C/C++, PL/SQL, Cobol, J*aScrip, Groovy 等。sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具来检测你的代码，帮助你发现代码的漏洞，Bug，异味等信息。

 

Sonar 不仅提供了对 IDE 的支持，可以在 Eclipse和 IntelliJ IDEA 这些工具里联机查看结果；同时 Sonar 还对大量的持续集成工具提供了接口支持，可以很方便地在持续集成中使用 Sonar。 

 

SonarQube是个开源的代码质量管理平台，可以通过多种工具和维度对代码质量进行分析，部分功能还支持可视化，对于代码缺陷一目了然。SonarQube比较开放，支持通过插件扩展功能，市面上常用的语言基本可以支持。同时，我们也可以尝试将sonar跟常用的jekins或者gocd集成在一起，在持续构建的同时对代码质量进行监测。该工具功能强大，使用简便，实乃程序员保证代码健康的*良药。

 

它的特点：易于安装、易于配置、可扩展（自己开发插件），并且它拥有数以百计的成熟插件，这种插件式的特点提供可做任何事情的可能。。

 

SonarQueb主要从以下7个维度检测评估代码质量：

1.糟糕的复杂度分布

文件、类、方法等，如果复杂度过高将难以改变，这会使得开发人员难以理解它们，

且如果没有自动化的单元测试，对于程序中的任何组件的改变都将可能导致需要*的回归测试

2.重复

显然程序中包含大量*粘贴的代码是质量低下的

sonar可以展示源码中重复严重的地方

3.缺乏单元测试

sonar可以很方便地统计并展示单元测试覆盖率及测试结果统计

4.没有代码标准

sonar可以通过oclint,PMD,CheckStyle,Findbugs等等代码规则检测工具规范代码编写

 

5.没有足够的或者过多的注释

没有注释将使代码可读性变差，特别是当不可避免地出现人员变动时，程序的可读性将大幅下降

而过多的注释又会使得开发人员将精力过多地花费在阅读注释上，亦违背初衷

6.潜在的bug

sonar可以通过oclint,PMD,CheckStyle,Findbugs等等代码规则检测工具检测出潜在的bug

7.糟糕的设计

通过sonar可以找出循环，展示包与包、类与类之间的相互依赖关系

可以检测自定义的架构规则

通过sonar可以管理第三方的jar包

可以利用LCOM4检测单个任务规则的应用情况

检测耦合

 

产品特点：

一目了然

l  无论你是想在文件，模块，项目或组合层面来管理代码质量，SonarQube众多的仪表板为你提供快速的洞察力。看看Nemo，SonarQube我们的公共实例，看看会期望发生什么。

所有利益相关者

l  很多仪表板可开箱即用，并且新的仪表盘可能性是无止境的，你是否希望把*放在措施或问题。用户可以创建完全定制的*仪表盘，只显示有价值的数据给他们。

七宗罪

l  该平台涵盖了的7种维度，也被称为开发商“七宗罪：重复，编码标准，覆盖面不足，潜在的错误，复杂性，文档和设计。

语言支持

l  支持超过20种不同的语言，包括支持J*a，C＃，C/ C++，COBOL，PL/ SQL，ABAP，使用J*a*ript，PHP，Web，XML等。该平台还提供了对这些语言添加自己的规则的能力。

时间机器

l  有几种方法可重放过去，展示您指标如何演变：表，时间表，动态图表等，这将确保随着时间的推移进度得到跟踪。

阻止泄漏！

l  当处理管道*裂，常理说，你应该在拖地前*泄漏。这就是为什么该平台提供了跟踪新代码质量的能力：近推出的新问题，对代码的测试覆盖率不足等问题，一旦发现，问题可以很容易地分配扫尾。

预提交检查

l  源代码可以推动改变SCM前进行检查：无论是直接在Eclipse或IntelliJ IDEA，或通过批处理使用问题报告插件：。这两个让你确保你不会引入新的质量问题。

放大到源

l  您正在寻找什么的，一个项目，一批项目，等等，你可以点击几下打*任何指标，并深入到信息的来源：源代码！

自动化

l  质量分析，可以很容易地集成到任何持续集成服务器到完全自动化的过程。这使您可以轻松持续地检查过程。

安全

l  认证和授权是一个是直接可用的完整机制，但它也可能安全委托给外部系统，如LDAP，活动目录等，或使用SSO。

扩展

l  扩展是DNA平台的一部分，可通过SonarQube插件库它可以扩展60多种插件。您也可以开发自己的插件。

集成

l  集成出来的标准ALM组件，如M*en， Ant， SVN，Git， Mercurial， JIRA， Mantis，Google Analytics，Piwik，Fortify等等

SonarQube是个开源的代码质量管理平台，可以通过多种工具和维度对代码质量进行分析，部分功能还支持可视化，对于代码缺陷一目了然。SonarQube比较开放，支持通过插件扩展功能，市面上常用的语言基本可以支持。同时，我们也可以尝试将sonar跟常用的jekins或者gocd集成在一起，在持续构建的同时对代码质量进行监测。该工具功能强大，使用简便，实乃程序员保证代码健康的*良药。

环境搭建部署

环境搭建包含两部分，数据库后台和sonarqube本身，sonarqube本身内嵌了H2用来存储分析数据，但是应用到生产环境并不合适，针对我们的情况还是单独部署数据库为好。

数据库配置

*支持对接四种数据库，Microsoft SQL Server、Or*e、PostgreSQL、MySQL（不推荐），我使用的是*tgresql数据库。其他几种数据库具体安装注意事项大家可以看*文档：Installing the Database
为了与其他应用隔离开，针对SonarQube单独建立相应的数据库、用户和*hema，在Mac OS以及Linux上，还需要建立相应的系统用户sonarqube。数据库建用户、建库等操作请自行google，另外，别忘记赋予数据库用户相应的建表等权限。
*hema名称为sonar，用户名称为sonarqube：

 

sonar=# \dn
  List of *hemas
  Name  |   Owner
--------+-----------
 public | *tgres
 sonar  | sonarqube

数据库名称也命名为sonar：

 

sonar=# \l
                              List of databases
   Name    |   Owner   | Encoding | Collate | Ctype |    Access privileges
-----------+-----------+----------+---------+-------+-------------------------
 open_lmis | *tgres  | UTF8     | C       | C     |
 *tgres  | *tgres  | UTF8     | C       | C     |
 sonar     | sonarqube | UTF8     | C       | C     | =Tc/sonarqube          +
           |           |          |         |       | sonarqube=CTc/sonarqube
 template0 | *tgres  | UTF8     | C       | C     | =c/*tgres            +
           |           |          |         |       | *tgres=CTc/*tgres
 template1 | *tgres  | UTF8     | C       | C     | =c/*tgres            +
           |           |          |         |       | *tgres=CTc/*tgres

这块需要注意的是，在*tgresql中，新建用户sonarqube默认的*hema还是指向public，而我们要使用新建的sonar，需要在数据库中执行以下命令将sonarqube的默认*hema改为sonar：

 

ALTER USER sonarqube SET search_path to sonar

SonarQube部署

sonarqube的部署非常简单，我的版本是7.3。后解压，然后执行bin目录中相应操作系统的启动即可，不过在这之前需要对数据库信息进行配置。配置方法是进入到解压后的文件夹的conf目录中，修改sonar.properties文件，文件中有很多配置项，不过都是被注释掉的。这个配置文件里面的说明非常详细，包括需要适配数据库的哪些版本等等。里面提示Postgresql需要在9.3版本及以上，我机器装的是9.4，刚好可以用，大家在安装相应版本的时也请仔细阅读这个配置里面的说明信息，因为版本问题出错。同时，也包含其他配置信息，暂时没有时间研究，我们先尽快把sonarqube跑起来再说。

 

(2.0-moz)⚡ % j sonar                                                                                                                                                              ~/IdeaProjects/open-lmis
/Users/zbao/Tool/sonarqube-7.3
% ll                                                                                                                                                                                   ~/Tool/sonarqube-7.3
total 16
-rw-r--r--@  1 zbao  staff   7.5K Aug 10 17:31 COPYING
drwxr-xr-x@  8 zbao  staff   256B Aug 10 17:31 bin
drwxr-xr-x@  4 zbao  staff   128B Sep  3 22:45 conf
drwxr-xr-x@  6 zbao  staff   192B Sep  3 22:46 data
drwxr-xr-x@ 11 zbao  staff   352B Aug 10 17:31 elasticsearch
drwxr-xr-x@  5 zbao  staff   160B Sep  3 17:52 extensi*
drwxr-xr-x@  7 zbao  staff   224B Aug 10 17:40 lib
drwxr-xr-x@ 16 zbao  staff   512B Sep  5 09:27 logs
drwxr-xr-x@  8 zbao  staff   256B Sep  5 21:19 temp
drwxr-xr-x@ 24 zbao  staff   768B Aug 10 17:40 web
% cd conf                                                                                                                                                                              ~/Tool/sonarqube-7.3
% ll                                                                                                                                                                              ~/Tool/sonarqube-7.3/conf
total 48
-rw-r--r--@ 1 zbao  staff    20K Sep  3 22:45 sonar.properties
-rw-r--r--@ 1 zbao  staff   3.1K Aug 10 17:31 wrapper.conf

这个配置现在只需要修改三个配置即可，数据库用户、数据库密码和jdbc的url：

 

# User credentials.
# Permissi* to create tables, indices and tri*er*ust be granted to JDBC user.
# The *hema must be created first.
sonar.jdbc.username=sonarqube
sonar.jdbc.password=password
#----- PostgreSQL 9.3 or greater
# If you don't use the *hema named "public",
sonar.jdbc.url=jdbc:*tgresql://localhost/sonar

sonarqube的web服务默认是全零在9000端口上，如果想修改，可以修改这两个配置，我用的是默认：

 

# Binding IP address. For servers with more than one IP address, this property specifies which
# address will be used for listening on the specified ports.
# By default, ports will be used on all IP addresses associated with the server.
sonar.web.host=0.0.0.0

# Web context. When set, it must start with forwa*lash (for example /sonarqube).
# The default value is root context (empty value).
#sonar.web.context=
# TCP port for incoming HTTP connecti*. Default value is 9000.
sonar.web.port=9000

修改完成后，进入bin目录，根据操作系统选择，我用的是Mac OS，直接使用下面命令启动：

 

% cd macosx-universal-64                                                                                                                                                           ~/Tool/sonarqube-7.3/bin
% ll                                                                                                                                                           ~/Tool/sonarqube-7.3/bin/macosx-universal-64
total 288
-rw-r--r--  1 zbao  staff     5B Sep  5 21:19 SonarQube.pid
drwxr-xr-x@ 3 zbao  staff    96B Aug 10 17:31 lib
-rwxr-xr-x@ 1 zbao  staff    15K Aug 10 17:31 sonar.sh
-rwxr-xr-x@ 1 zbao  staff   123K Aug 10 17:31 wrapper
% sh sonar.sh start                                                                                                                                            ~/Tool/sonarqube-7.3/bin/macosx-universal-64
Starting SonarQube...
Started SonarQube.

启动后，查询sonar数据库里面新建了不少表，说明sonarqube已经在启动时将必须的数据刷进去了，下面是其中的部分表：

 

sonar=> \d
                        List of relati*
 Schema |              Name               |   Type   |   Owner
--------+---------------------------------+----------+-----------
 sonar  | active_rule_parameters          | table    | sonarqube
 sonar  | active_rule_parameters_id_seq   | sequence | sonarqube
 sonar  | active_rules                    | table    | sonarqube
 sonar  | active_rules_id_seq             | sequence | sonarqube
 sonar  | alm_app_installs                | table    | sonarqube
 sonar  | analysis_properties             | table    | sonarqube
 sonar  | ce_activity                     | table    | sonarqube
 sonar  | ce_activity_id_seq              | sequence | sonarqube
 sonar  | ce_queue                        | table    | sonarqube
 sonar  | ce_queue_id_seq                 | sequence | sonarqube
 sonar  | ce_*anner_context              | table    | sonarqube
 sonar  | ce_task_characteristics         | table    | sonarqube
 sonar  | ce_task_input                   | table    | sonarqube
 sonar  | default_qprofiles               | table    | sonarqube
 sonar  | deprecated_rule_keys            | table    | sonarqube
 sonar  | duplicati*_index              | table    | sonarqube
 sonar  | duplicati*_index_id_seq       | sequence | sonarqube
 sonar  | es_queue                        | table    | sonarqube

数据库表中有张user表，是用来存储用户信息的，默认用户名和密码均为admin和admin，次登陆系统需要输入这个密码：

 

 

 

 

 

 

过不断分析代码以了解潜在的质量问题，开源的 SonarQube 项目支持了 DevOps 的“尽早发布和经常发布” 的思维模式。

越来越多的*正在实施 DevOps 以便在通过中间开发和测试环境以后更快更好的将新代码引入到生产环境。虽然版本控制、持续集成和部署以及自动化测试都属于 DevOps 的范畴，但仍然存在一个关键问题：*如何量化代码质量，而不仅仅是部署的速度？

SonarQube 是用来填补这个空隙的一种选择。它是一个开源平台，通过代码的自动化静态分析不断的检查代码质量。 SonarQube 支持 20 多种语言的分析，并在各种类型的项目中输出和存储问题。

SonarQube 同时也提供了一个可同时维护和管理不同项目、不同代码的集中的环境。可以为每个项目定制规则。持续的检查和分析代码的健康轨迹。

SonarQube 还可以集成到可持续集成和开发（CI/CD）流程中，协助和自动确定代码是否为生产环境做好了准备的过程。

 

它可以衡量什么

开箱即用，SonarQube 可以测量的关键指标，包括代码错误、代码异味code *ells、安全漏洞和重复的代码。

• 代码错误 是代码中的一部分不正确或无法正常运行、可能会导致错误的结果，是指那些在代码发布到生产环境之前应该被*的明显的错误。

• 代码异味 不同于代码错误，被检测到的代码是可能能正确执行并符合预期。然而，它不容易被*，也不能被单元测试覆盖，却可能会导致一些未知的错误，或是一些其它的问题。从长期的可维护性来讲，立即*代码异味是明智之举。通常在编写代码的时候，代码异味并不容易被发现，而 SonarQube 的静态分析是一种发现它们的很好的方式。

• 安全漏洞 正如听起来的一样：指的是现在的代码中可能存在的安全问题的缺陷。这些缺陷应该立即*来*利用它们。

• 重复的代码 也和听起来的一样：指的是源代码中重复的部分。代码重复在软件设计中是一种很不好的做法。总的来说，如果对一部分代码进行更改而另一部分没有，则会导致一些维护性的问题。例如，识别重复的代码可以很容易的将重复的代码打包成一个库来重复的使用。

可自定义的选项

因为它是开源的，所以 SonarQube 鼓励用户开发和提供可定制的选项。目前有超过 60 个插件 可用于增强 SonarQube 开箱即用的分析功能。

大多数的插件是为了增加 SonarQube 可以分析的编程语言的数量。另一些插件可以分析一些额外的指标甚至包括一些显示的仪表盘视图。实际上，如果*需要检查一些自定义指标，或是想要在自己的仪表盘和以特定的方式查看分析数据，或使用 SonarQube 不支持的编程语言，则可能存在一些自定义的选项可以使用。如果你想要的功能并不支持，SonarQube 源码的开放也为你自己开发新的功能提供了可能性。

用户还可以定制适用于每种特定编程语言分析器的规则。通过 SonarQube 用户界面，可以按语言和按项目选择和取消规则。这些为特定的项目*的规则，可以很好的在一个集中的位置维护所有的数据和配置。

为什么它那么重要

SonarQube 为*提供了一个集中的位置来管理和跟踪多个项目代码中的问题。它还可以把持续的检查与质量门限相结合。一旦项目分析过一次以后，更进一步的分析会参考软件的修改来更新原始的统计信息，以反映的变化。这些跟踪可以让用户看到问题解决的程度和速度。这与 “尽早发布并经常发布”不谋而合。

另外，SonarQube 可使用 可持续集成流程，比如像 Hudson 和 Jenkins 这样的工具。这个质量门限可以很好的反映代码的整体运行状况，并且通过 Jenkins 等集成工具，在发布代码到生产环境时担任一个重要的角色。

本着 DevOps 的精神， SonarQube 可以量化代码质量，来达到*内部的要求。为了加快代码生产和发布的周期，*必须意识到它们自己的技术*和软件问题。通过发现这些信息， SonarQube 可以帮助*更快的生成高质量的软件。

想要了解更多吗？

SonarQube 基于 GUN 通用公共许可证发布，它的源码可以在 GitHub 上查看。越来越多的用户对 SonarQube 的特性和功能感兴趣。 Twitter 和 Google 上有活跃的社区。这些社区以及 SonarQube 博客 对任何有兴趣开始和使用 SonarQube 的人有很有帮助。