精华内容
下载资源
问答
  • 代码质量检查

    千次阅读 2014-09-26 19:25:32
    代码质量概述  怎样辨别一个项目代码写得好还是坏?优秀的代码和腐化的代码区别在哪里?怎么让自己写的代码既漂亮又有生命力?接下来将对代码质量的问题进行一些粗略的介绍。也请有过代码质量相关经验的朋友提出...

    代码质量概述

        怎样辨别一个项目代码写得好还是坏?优秀的代码和腐化的代码区别在哪里?怎么让自己写的代码既漂亮又有生命力?接下来将对代码质量的问题进行一些粗略的介绍。也请有过代码质量相关经验的朋友提出宝贵的意见。

    image

        代码质量所涉及的5个方面,编码标准、代码重复、代码覆盖率、依赖项分析、复杂度分析。这5方面很大程序上决定了一份代码的质量高低。我们分别来看一下这5方面:

    编码标准:这个想必都很清楚,每个公司几乎都有一份编码规范,类命名、包命名、代码风格之类的东西都属于其中。

    代码重复:顾名思义就是重复的代码,如果你的代码中有大量的重复代码,你就要考虑是否将重复的代码提取出来,封装成一个公共的方法或者组件。

    代码覆盖率:测试代码能运行到的代码比率,你的代码经过了单元测试了吗?是不是每个方法都进行了测试,代码覆盖率是多少?这关系到你的代码的功能性和稳定性。

    依赖项分析:你的代码依赖关系怎么样?耦合关系怎么样?是否有循环依赖?是否符合高内聚低耦合的原则?通过依赖项分析可以辨别一二。

    复杂度分析:以前有人写的程序嵌套了10层 if else你信吗?圈复杂度之高,让人难以阅读。通过复杂度分析可以揪出这些代码,要相信越优秀的代码,越容易读懂。

        上面解释了代码质量相关的5个方面,在实际开发环境中,已经有很多工具为我们解决以上5个方面的问题,下列5个eclipse插件分别对这5个问题有很好的支持:

    编码标准:CheckStyle  插件URL:http://eclipse-cs.sourceforge.net/update/

    代码重复:PMD的CPD  插件URL:http://pmd.sourceforge.net/eclipse/

    代码覆盖率:Eclemma 插件URL:http://update.eclemma.org

    依赖项分析:JDepend 插件URL:http://andrei.gmxhome.de/eclipse/

    复杂度分析:Eclipse Metric  插件URL:http://metrics.sourceforge.net/update

    注:某些插件需要科学上网才能更新

    编码标准(CheckStyle的使用)

        在eclipse上安装好了CheckStyle插件后,我们来建一个类用它跑一下。这个类很简单,一个常见的用户实体,包含了id,用户名、密码、邮件等属性,并包含get set方法,一个标准的POJO。运行CheckStyle检查一下:

    image

    一个我们平时再普通不过的一个类,被checkstyle弄出这么多问题,情何以堪,我们来看看究竟是什么情况?

    看一下这些警告信息:

    line 1、image,说缺少package-info.java文件。

    line 2、image,说第一句注释要以“.”结尾。

    line 30、image,缺少java doc注释。

    line 35、image,getId不是继承的方法,必须指定abstract,final或空。另外也缺少java doc注释。

        这个类基本就这四类毛病,缺少package-info.java文件,这个文件是做什么的呢?他是用来描述包注释的类,有一定的特殊性,要想详细了解请百度。如果对你的项目没有太大的影响,可以忽略它。配置CheckStyle的方法我们等会再说。第一句注释要以“.”结尾,这看你的习惯,你确定需要这个,你就保留,不需要就忽略。缺少java doc,对于java类的属性来说,注释是必要的,所以这个要保留。不是继承的方法,需要加上final关键字,如果你有这个习惯,就保留,反之忽略。

    我们这里只是建立了一个最简单的类用CheckStyle来检查,随着你的类代码越来越多,逻辑越来越复杂,CheckStyle能检查出来的毛病也越来越多。常见的CheckStyle错误有这些:

    1.Type is missing a javadoc commentClass   
    缺少类型说明 
    2.“{” should be on the previous line 
    “{” 应该位于前一行 
    3.Methods is missing a javadoc comment 
    方法前面缺少javadoc注释 
    4.Expected @throws tag for “Exception” 
    在注释中希望有@throws的说明 
    5.“.” Is preceeded with whitespace “.” 
    前面不能有空格 
    6.“.” Is followed by whitespace“.” 
    后面不能有空格 
    7.“=” is not preceeded with whitespace 
    “=” 前面缺少空格 
    8.“=” is not followed with whitespace   
    “=” 后面缺少空格 
    9.“}” should be on the same line    
    “}” 应该与下条语句位于同一行 
    10.Unused @param tag for “unused” 
    没有参数“unused”,不需注释 
    11.Variable “CA” missing javadoc 
    变量“CA”缺少javadoc注释 
    12.Line longer than 80characters   
    行长度超过80 
    13.Line contains a tab character 
    行含有”tab” 字符 
    14.Redundant “Public” modifier 
    冗余的“public” modifier 
    15.Final modifier out of order with the JSL 
    suggestionFinal modifier的顺序错误 
    16.Avoid using the “.*” form of import 
    Import格式避免使用“.*” 
    17.Redundant import from the same package 
    从同一个包中Import内容 
    18.Unused import-java.util.list 
    Import进来的java.util.list没有被使用 
    19.Duplicate import to line 13 
    重复Import同一个内容 
    20.Import from illegal package 
    从非法包中 Import内容 
    21.“while” construct must use “{}” 
    “while” 语句缺少“{}” 
    22.Variable “sTest1” must be private and have accessor method 
    变量“sTest1”应该是private的,并且有调用它的方法 
    23.Variable “ABC” must match pattern “^[a-z][a-zA-Z0-9]*$”      
    变量“ABC”不符合命名规则“^[a-z][a-zA-Z0-9]*$” 
    24.“(” is followed by whitespace    
    “(” 后面不能有空格 
    25.“)” is proceeded by whitespace 
    “)” 前面不能有空格

        可以看出CheckStyle检查出来的问题,大多是编码规则以及风格上的问题,这是编写高质量代码最基本的。值得注意的是,我们将一些优秀的开源代码用CheckStyle来检查也会检查出不少问题,这不能不说这些开源不优秀,而是每个公司组织有自己的编写规范度,这个度既可以减少程序员的工作量又可以让代码的可读性合格,但这个度不一样符合CheckStyle的完整标准。所以我们一般使用CheckStyle都不会用他的默认标准,而是通过配置,制定适合自己的编码规则。

    自定义CheckStyle规则:

    image

        打开CheckStyle配置,新建一个配置,选择外部配置文件。在这之前最好导出一个eclipse自带的checkstyle配置文件(sun_checks.xml),然后重命名作为一个外部的配置导进去,这么做的目的是导入之后可以修改相应的配置,达到自定义配置的目的(因为eclipse自带的配置是加锁的,不能修改)。导入之后,点击右边的“Configure”进行编辑。

    先去掉缺少package-info.java文件的提示

    image

    再将第一句注释要以“.”结尾这个规则去掉,双击“Style javadoc”,将窗口内“checkFirstSentence”勾选去掉。

    image

    对于实体类,属性有了注释,get set方法也不需要注释了,双击“Method javadoc”将allowMissingPropertyJavadoc勾选中。

    image

    “getId不是继承的方法,必须指定abstract,final或空”,如果你懒得在方法上加“final”,这条规则也可以去掉。

    image

    如果你不想每一个参数都加“final”,还需要把参数的final规则去掉:

    image

    另外还有一个错误“'id' hides a field.”,原因是方法的参数和类里面定义的域重名了,但使用eclipse生成的get set方法都会这样,所以可以忽略此项。

    image

    至此我们再使用checkstyle检查一篇,发现仅剩下属性缺少注释这个警告。

    image

    对每个属性加上java doc注释,所有问题都清除了。以此类推,解决checkstyle问题的方法就是:1、按规则解决代码问题;2、如果觉得这个问题对你的项目质量影响不大,则可以忽略它。

    代码重复(PMD的CPD的使用)

        对于多人开发的项目,难以避免出现重复代码的问题,尽管我们尽量对共用的代码进行了封装,但随着需求的增加、人员技术水平差异、沟通不足等原因,重复代码会越来越多。这不仅严重影响代码质量,也无形中增加了代码量。

    注:精简的程序和高复用度的代码是我们一直追求的目标。

    PMD的CPD工具就是为检查重复代码而生的。右键项目--->PMD---->Find Suspect Cut and Paste,执行重复代码检查:

    image

    检查出来的重复代码,可以双击查看。然后根据业务逻辑以及代码特征,决定要不要做封装、怎么封装。

    代码覆盖率(Eclemma的使用)

        一份质量合格的代码,不仅包含功能程序本身也包含了对应的测试代码,Eclemma插件可以用来统计测试代码覆盖整体代码中的比率,以此来评估代码的功能性和稳定性。

    使用Junit编写好测试用例之后,右键Coverage As--->Junit Test,运行测试用例,Eclemma会统计出相关的代码覆盖率:

    image

    根据这个结果,你可以看出自己编写的测试用例覆盖到了那些代码,而没有覆盖到的代码,则有可能成为代码质量的盲区。

    依赖项分析(JDepend的使用)

        随着程序业务逻辑的增加,代码的依赖关系也变的越来越复杂,JDepend插件可以统计包和类的依赖关系,分析出程序的稳定性、抽象性和是否存在循环依赖的问题。右键包--->Run JDepend Analysis:

    image

    看一下这几项指标:

    CC(Number of Classes)

    被分析package的具体和抽象类(和接口)的数量,用于衡量package的可扩展性。如果一个类中实现了其他类,如实现了监听类,则监听类的数目也记录在此。

    AC(Abstract classes)

    抽象类和接口的数量。

    Ca(Afferent Couplings)

    依赖于被分析package的其他package的数量,用于衡量pacakge的职责。即有多少包调用了它。

    Ce(Efferent Couplings)

    被分析package的类所依赖的其他package的数量,用于衡量package的独立性。即它调用了多少其他包。

    A(Abstractness)

    被分析package中的抽象类和接口与所在package所有类数量的比例,取值范围为0-1。

    I(Instability)

    I=Ce/(Ce+Ca),用于衡量package的不稳定性,取值范围为0-1。I=0表示最稳定,I=1表示最不稳定。即如果这个类不调用任何其他包,则它是最稳定的。

    D(Distance)

    被分析package和理想曲线A+I=1的垂直距离,用于衡量package在稳定性和抽象性之间的平衡。理想的package要么完全是抽象类和稳定(x=0,y=1),要么完全是具体类和不稳定(x=1,y=0)。取值范围为0-1,D=0表示完全符合理想标准,D=1表示package最大程度地偏离了理想标准。即你的包要么全是接口,不调用任何其他包(完全是抽象类和稳定),要么是具体类,不被任何其他包调用。

    Cycle

    循环依赖的数量。

    有个这个报告我们就可以有针对性的对代码进行设计和重构。

    复杂度分析(Metrics的使用)

        对于阅读代码的人来说,越简单的代码越好理解和维护,如果你的代码阅读起来很费劲或者你自己过段时间后再来看都看不懂,你就得想办法解决下代码的复杂度问题了。Metrics插件可以帮你做到这点。

    首先在Java透视图下右键一个项目---->Properties,选择Metrics,勾选Enble Metrics。

    image

    然后Window--->Show View---->Other---->Metrics View

    image

    打开Metrics视图,点击右上角运行图标,即可得到复杂度分析的结果:

    image

    可以根据复杂度指标,对自己的程序进行优化。

    小结

        本文介绍了和java代码质量相关的5个方面问题,并介绍对应eclipse插件的用法和作用。在我们实际开发中,尽量根据自己公司和团队的情况来制定一些检查规则,来提高代码质量。并且在大多数情况下,会有两个检查环节,即本地检查和持续集成环境的检查,我们常用的Hudson就可以集成很多插件。

    参考资料:

    追求代码质量: 软件架构的代码质量 
    http://www.ibm.com/developerworks/cn/java/j-cq04256/ 
    JDepend 
    http://www.clarkware.com/software/JDepend.html 
    PMD 
    http://pmd.sourceforge.net/ 
    CheckStyle 
    http://sourceforge.net/projects/eclipse-cs/?source=directory 
    Eclemma 
    http://www.eclemma.org/ 
    Metrics 

    http://metrics.codahale.com/



    转载:http://www.cnblogs.com/leefreeman/p/3585032.html


    展开全文
  • Code Quality Checker 代码质量检查
  • 代码质量检查是持续性的工作,检查的两个基本工具是FindBugs和CheckStyle。在实际项目中,检查的工作由测试人员实施,开发人员进行配合,形成日常性的工作。每天会对最新的代码进行检查,使用脚本(一般是测试用...

    代码质量检查是持续性的工作,检查的两个基本工具是FindBugs和CheckStyle。在实际项目中,检查的工作由测试人员实施,开发人员进行配合,形成日常性的工作。每天会对最新的代码进行检查,使用脚本(一般是测试用python写的)对检查结果进行解析,定位到代码行并根据SVN记录关联责任人,输出邮件,开发则根据邮件结果进行修复。

    对于代码进行质量检查,在刚开始会有一些抵触情况。有的是之前没有接触过,有的是觉得需求已经很紧了,还要花时间解决这些问题。还有一方面原因是一刚开始扫描出来的问题会特别多,特别是代码规范的问题,好几千条。但只要走出第一步,熟悉了规则,解决了一些问题积累经验,后面的问题就比较少了。

    FindBugs

    FindBugs是针对java的静态分析工具,根据经验,确实能发现一些没有意识到的问题,对提高代码质量还是有帮助。扫出的问题以java文件为单位,会定位到代码行,并给出问题说明,处理起来也比较方便。

    FindBugs有一些规则和级别,如果觉得有一些规则没太大必要可以进行调整。印象中有两个规则大家觉得比较“无聊”:第一个是有变量申明了但没有使用,第二个是没在静态函数中访问静态变量。这两个如果不处理也没什么问题,但还是最好处理,形成最佳实践。比如有没有使用的变量,可能是代码有Bug,应该使用的,笔误成了其它的变量;确实没有使用的话,就应该删掉。

    FindBugs在实际项目中,没有集成到Android Studio,是测试对指定的代码目录进行了扫描。详细的使用方法可参考FindBugs的官网。

    CheckStyle

    CheckStyle是代码规范分析工具,保证团队的代码符合一个统一的代码规范。CheckStyle的检查也是根据定义的规范文件来的。实际项目中使用的规范文件据说是华为使用的,Github上有下载,我们使用的也是这份规范,并补充了一些规则。

    CheckStyle有一个Android的插件,因些一般是集成到Android Studio中。

    //添加Plugin

    apply plugin: 'checkstyle'

    //设置CheckStyle版本

    /**

    * 检查代码规范的checkstyle

    * http://ju.outofmemory.cn/entry/187977

    */

    checkstyle {

    toolVersion '6.0'

    showViolations true

    }

    //设置配置文件

    task checkstyle(type: Checkstyle) {

    configFile file("config/checkstyle/checkstyle.xml")

    source 'src/main/java'

    include '**/*.java'

    exclude '**/gen/**'

    ignoreFailures true

    classpath = files()

    }

    配置好后,要进行检查,执行gradle checkstyle任务就好了,最终检查结果会生成HTML和XML文件。结果也是同FindBugs一样生成报告邮件。

    在实际项目中,有争议的还是规则。有些人之前没有进行过代码规范的训练,已经形成了自己的习惯,扫描出来问题就特别多,但还是以规则为主;且规则不宜作太大的修改,尽量跟公司内还有业界保持一致。

    有些规则的细节,可根据项目实际情况调整。比如函数最多参数个数这个规则就调了好几次,因为加入了一些历史代码,且不太好修改,只好调整规则。比如重复代码的行数,开始定10行,后来发现空行也算进去了,后面又调整成15行。其他的一些规则,如变量命名、方法命名则没有什么好商量的,按规则的来,习惯就好了。

    Lint Clean

    在实际项目中,我们还使用了一个LintClean这个工具。主要作用是清除项目中没有使用的资源文件及资源项,如有个xml、png或字符串没有引用。它会扫描出来并进行删除,也会将扫描结果保存到xml。通过持续清除项目中无效资源,即可保证工程整洁,也能防止包文件过大,虽然混淆也会清除无效资源,但还是有一定影响。

    这个工具也是插件形式提供的,也可集成到项目,

    dependencies {

    classpath 'com.droidtitan:lint-cleaner-plugin:0.3.0'

    }

    apply plugin: 'com.droidtitan.lintcleaner'

    配置好后,执行gradle lintClean,就可进行检查。有时,有些资源可能是resources.getIdentifier的使用的,这样就要加一些白名单。LintClean也提供了加白名单的功能。检查的结果也是由测试人员编写的脚本进行解析,定位到责任人,形成报告并发送邮件。

    跟LintClean一起,我们还加了另一个功能,就是扫描资源目录下的png、jpg等图片资源文件,当发现文件大小超过100KB,会单独列出来,当成文件过大警告。根据项目的实际经验,一般单张图片大小比较少的情况下需要100K。

    展开全文
  • JSHint 是一个 JavaScript 的代码质量检查工具,主要用来检查代码质量以及找出一些潜在的代码缺陷。 该工具也提供在线版本,请点击下面的软件首页。 标签:JSHint
  • 使用Gradle做Java代码质量检查Maven --> Gradle首先安装gradle:Mac安装brew install gradleUbuntu安装apt install gradleMaven项目切换Gradle项目,再Maven根目录下运行:gradle init --type pom运行成功之后运行...

    使用Gradle做Java代码质量检查

    Maven --> Gradle

    首先安装gradle:
    Mac安装

    brew install gradle

    Ubuntu安装

    apt install gradle

    Maven项目切换Gradle项目,再Maven根目录下运行:

    gradle init --type pom

    运行成功之后运行命令gradle build,成功之后删除pom.xml即可。

    使用jacoco分析单元测试

    jacoco是一个分析单元测试覆盖率的工具,使用它运行单元测试后,可以给出代码中那些部分被单元测试到,哪些部分没有被单元测试覆盖,并且还会给出整个项目的单元测试覆盖情况。
    build.gradle中添加jacoco插件

    apply plugin: 'jacoco'

    运行命令进行单元测试分析

    gradle jacocoTestReport

    或者可以再Gradle的工具菜单中Tasks -> other -> jacocoTsestReport可以直接启动单元测试的分析。

    0816a8e7f7ac50222e7686d7ee8e7f8f.png


    在项目中build目录下可以看到jacoco目录,以及reports/test/html目录,后者主要是jacoco生成的报告。

    43d6799aa4c15957f3187ec4373623f7.png

    使用SonarQube做代码质量检查

    SonarQube是一个开源的代码质量管理系统,支持超过25种编程语言,提供重复代码、编码标准、单元测试、单元测试覆盖率,代码复杂度,潜在Bug、注释和软件设计的报告等。
    在gradle中使用SonarQube首先要添加依赖,在编译脚本中添加:

    buildscript {
        repositories {
            maven { url "https://plugins.gradle.org/m2/" }
        }
        dependencies {
            classpath("org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.6-rc1")
            classpath("org.springframework.boot:spring-boot-gradle-plugin:2.0.5.RELEASE")
        }
    }

    添加插件:

    apply plugin: "org.sonarqube"

    配置SonarQube:

    sonarqube {
        properties {
            property "sonar.sourceEncoding", "UTF-8"
            property "sonar.host.url", "https://sonarcloud.io"
            property "sonar.jdbc.url", "jdbc:mysql://my.server.com/sonar"
            property "sonar.jdbc.driverClassName", "com.mysql.jdbc.Driver"
            property "sonar.login", "test"
            property "sonar.password", "test"
    
        }
    }

    或者只使用token上传分析结果即可:

    property "sonar.login", "token"

    SonarQube本身并没有提供单元测试覆盖率的工具,需要在使用jacoco的分析结果,在SonarQube中添加jacoco相关的配置

    sonarqube {
        properties {
    
            property "sonar.jacoco.reportPath", "$rootDir/build/jacoco/test.exec"
            property "sonar.jacoco.itReportPath", "$rootDir/build/jacoco/acceptanceTest.exec"
            property "sonar.jacoco.excludes", "*/st/*"
    
            property "sonar.sourceEncoding", "UTF-8"
            property "sonar.host.url", "https://sonarcloud.io"
            property "sonar.jdbc.url", "jdbc:mysql://my.server.com/sonar"
            property "sonar.jdbc.driverClassName", "com.mysql.jdbc.Driver"
            property "sonar.login", "test"
            property "sonar.password", "test"
    
        }
    }

    运行命令gradle sonarqube即可对代码进行分析,并上传分析结果,因为SonarQube的分析依赖jacoco的单元测试分析,所以需要先运行命令gradle jacocoTestReport。最终需要运行的组合命令是:

    gradle jacocoTestReport
    gradle sonarqube
    展开全文
  • jenkins代码质量检查 在持续交付中,每个构建都可以交付 。 这个事实意味着,除其他外,要尽可能快地为您的组件分配无快照版本,以便您可以在所有过程中引用它们。 通常,自动化软件交付过程包括多个阶段,例如提交...

    jenkins代码质量检查

    持续交付中,每个构建都可以交付 这个事实意味着,除其他外,要尽可能快地为您的组件分配无快照版本,以便您可以在所有过程中引用它们。 通常,自动化软件交付过程包括多个阶段,例如提交阶段,代码质量,验收测试,手动测试,部署 ………但是让我们集中讨论与代码质量相关的第二阶段。 请注意,在我之前的文章( http://www.lordofthejars.com/2013/02/conditional-buildstep-jenkins-plugin.html )中,这里使用了一些概念。

    连续交付的 第二阶段是代码质量。 这一步非常重要,因为这是我们运行静态代码分析以检测可能的缺陷的地方

    (通常是NPE ),代码约定或不必要的对象创建。 通常使用的一些项目包括CheckstylePMDFindBugs等。 在这种情况下,我们将看到如何使用Checkstyle ,但是在其他任何工具中它当然都非常相似。 因此,要做的第一件事是将Checkstyle配置为我们的构建工具(在本例中为Maven )。 因为我们只想在管道的第二阶段运行静态分析,所以我们将把Checkstyle Maven插件注册到指标配置文件中。 请记住,所有用于代码分析的插件都应添加到该配置文件中。

    <profiles>
       <profile>
         <id>metrics<id>
         <build>
           <plugins>
           <!--  CHECKSTYLE  -->
             <plugin>
               <groupId>org.apache.maven.plugins<groupId>
               <artifactId>maven-checkstyle-plugin<artifactId>
               <version>2.9.1<version>
             <plugin>
           <plugins>
         <build>
       <profile>
     <profiles>

    现在我们已经用Checkstyle配置了pom ,我们可以配置Jenkins在第一阶段之后运行代码质量阶段(在我之前的文章中有解释)。 在这种情况下,我们将使用Trigger Parameterized Build插件从提交阶段执行代码质量作业。 因为当前构建版本的代码在提交阶段已被推送到发行分支(请参阅我的一篇文章),所以我们需要将分支名称设置为代码质量Jenkins作业的参数,以便可以下载代码然后运行静态分析。

    在第一阶段的构建工作中,我们在其他项目上添加类型为Trigger参数化构建Post-build Action 首先,我们打开管道的第一个构建作业的Configure菜单,然后对其进行配置,以便仅当当前作业稳定时才执行管道的下一个构建作业( helloworld-code-quality )。 另外,我们使用分支名称定义RELEASE_BRANCH_NAME参数。

    然后让我们创建一个新的构建作业,该作业将负责运行静态代码分析,我们将其命名为helloworld-code-quality 然后,我们配置新的构建作业。 首先,检查选项“ 此构建已参数化 ”,并添加String参数并设置名称RELEASE_BRANCH_NAME 之后,我们可以在当前作业中使用RELEASE_BRANCH_NAME参数。 因此,在“ 源代码管理”部分,我们添加了存储库URL ,在“ 分支”中,我们设置了origin / $ {RELEASE_BRANCH_NAME}

    然后在构建部分,我们添加一个Maven构建步骤,该步骤执行Checkstyle目标: checkstyle:checkstyle -P指标。 最后,为了更好地了解结果,我们可以安装Checkstyle Jenkins插件并发布报告。 安装插件后,我们可以添加一个名为“ 发布Checkstyle分析结果 ”的新的构建后操作 在我们的案例中,报告位于** / target / checkstyle-result.xml

    这就是当前阶段的全部内容,下一阶段负责执行验收测试,但这将在另一篇文章中。 因此,总而言之,我们了解了在编译代码并执行一些测试之后(在管道的第一阶段),如何使用Checkstyle Maven插件将代码质量阶段运行到Jenkins中

    参考:One Jar To Rule Them All博客中, 使用我们JCG合作伙伴 Alex Soto的Jenkins进行代码质量阶段

    翻译自: https://www.javacodegeeks.com/2013/02/code-quality-stage-using-jenkins.html

    jenkins代码质量检查

    展开全文
  • 主要介绍了Jenkins集成sonarQube实现代码质量检查过程图解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
  • Recess 是一个简单的建立在动态样式语言 LESS 上的代码质量检查工具。它能够直接作为一个编译器被集成到构建系统中,并使你的代码看起来更加整洁和易于管理。 标签:Recess 分享 ...
  • Sonar 代码质量检查模块 转载于:https://www.cnblogs.com/tongbiao/p/10917783.html
  • 主要介绍了使用Gradle做Java代码质量检查的方法示例,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • 前言最近在研究代码质量检测和分析这一个环节,当然代码质量分析是devops中持续集成部分非常重要的一个环节。涉及到团队协作的时候,很多公司会有自己的一套规则,最熟悉的是阿里巴巴的java代码参考手册,专家总结,...
  • SonarQube(sonar)是一个开源平台,用于管理源代码的质量。 SonarQube不只是一个质量数据报告工具,更是代码... SonarQube可以从以下七个维度检测代码质量,而作为开发人员至少需要处理前5种代码质量问题。(1) 不遵循...
  • java代码质量检查工具

    千次阅读 2018-03-03 15:31:45
    Java代码质量检查工具及使用案例 在现在的软件开发中,由于软件的复杂度越来越高,业务也覆盖很广,各个业务模块业务错综复杂。这样就需要我们需要团队开发,在我们团队中开发人员的经验、代码风格样式都不一致,...
  • SonarQube是一款代码质量检查工具,本文介绍SonarQube的安装、配置与几本使用
  • Apache JMeter ... idea插件 ...findbugs 代码质量检查 根据缺陷的性质,大致可以分为下列几类 ·Bad practice 不好的做法 ·Correctness 可能有不正确 ·Dodgy code 糟糕的代码 ·Experi...
  • 相对于后端,前端代码规范的质量检查涉及到HTML, CSS,Javascript ,如今还涉及到SCSS,ES5,JSX, React,Vue,Angular等,更是复杂。本文提供了在检查工具方面的规则制定,在编辑器IDE中进行配置,在webpac...
  • Docker搭建SonarQube代码质量检查平台

    千次阅读 2018-12-29 20:30:14
    SonarQube是一个用于持续检查代码...Docker搭建SonarQube代码质量检查平台   快速开始 version: '3' services: mydb: image: postgres:11 volumes: - ./data:/var/lib/postgresql/data environment: P...
  • 目前基本使用三款js代码质量检查工具: jslint, jshint, eslint。许多IDE里面也有对应的检查插件,在每次ctrl + s 保存文件的时候,检查当前文件是否符合规范,保证代码质量。许多团队都会指定一套代码规范code ...
  • 220121212Please provide the prefix of Imagemagick installation [autodetect]:building in/tmp/pear/temp/pear-build-rootc0ls2V/imagick-3.0.1running: /tmp/pear/temp/imagick/configure --with-imagickcheckin...
  • jacoco报告 使用SonarQube做代码质量检查 SonarQube是一个开源的代码质量管理系统,支持超过25种编程语言,提供重复代码、编码标准、单元测试、单元测试覆盖率,代码复杂度,潜在Bug、注释和软件设计的报告等。...
  • jenkins集成sonarqube进行代码质量检查 1.搭建环境和下载工具包 1.1搭建环境 window系统+Jdk1.8+mysql5.6+python3.6 1.2下载工具包 工具包 描述 下载地址(未精确到版本号) sonarqube-7.4.zip sonarqube...
  • 在做Java项目的时候,我们经常会使用 Sonar Qube来进行代码质量检查工作。查看了一下其文档,sonar qube不仅可以做Java的检查,还支持其他语言,比如js, ts等等。 本文简单记录如何配置sonar服务,如何使用其进行...
  • Sonar 用于代码质量管理的开放平台。通过插件机制,Sonar 可以集成不同的测试工具,代码分析工具,以及持续集成工具
  • Java代码质量检查工具及使用案例

    千次阅读 2017-11-08 11:30:58
    Java代码质量检查工具及使用案例 在现在的软件开发中,由于软件的复杂度越来越高,业务也覆盖很广,各个业务模块业务错综复杂。这样就需要我们需要团队开发,在我们团队中开发人员的经验、代码风格样式都不一致,...
  • 1.目标 之前已经写过一篇关于Jenkins和... 使用SonarQube进行代码质量检查,访问SonarQube Server,可以查看代码质量检查报告。 2.环境说明  jdk:sun JDK1.8.0_20 64bit  MySQL:5.7.13  sonarqub...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,753
精华内容 1,501
关键字:

代码质量检查