Scala style -静态代码分析工具 - “替罪羊”scapegoat

欢迎转载,转载请注明出处.

敏捷和团队化运作让迭代交付压力剧增,开发者即使996也不堪重负.为了减负大家采用各种手段:统一项目编码规范是其中之一。在强大的压力面前,规范执行情况和效果,就不一而足了。

我们为了保证项目编码风格一致性和规避常见的错误,代码自动化检查加入代码管理中自然而然的选择。

我们部门一兄弟收到的点评是这样:”人生最全bug合集收藏家“、”bug富裕程度直逼马爸爸“、”文科生的代码样式“、”部门的百科全书“... ... 调侃归调侃,大家会诊结果是:

  • 主观:各种个性化的编码方法
  • 客观:在腐化代码的基础上维护和扩展功能

归根结底是项目不规范运作,对规范执行不力。静态分析是代码风格治理好的思路。

“痛的思变,是人的天性”。自动化代码检查是我们的目标。如果像下图一样列出潜在的可疑问题,对开发者而言是福利,对维护者而言是福音。
scapegoat检查结果

静态检查是自动化代码检查的一种。在静态代码检查领域,检查方式就那么几个流派。一种是检查源代码、一种检查字节码。我们今天介绍一种scala静态检查工具。scalastyle属于前者,scapegoat属于后者。

本篇我们介绍开源scala自动化代码检查工具- scapegoat。


scapegoat 是什么?

scapegoat是基于字节码来检查分析scala代码分析工具。原理是基于scala的编译器和反射机制,对推导和优化后的编码进行分析,是一款可媲美 findbugs的 数据流分析利器。

对比同类检查工具,用作者本人话说:不影响其它工具运行,且尽量多分析代码中可疑问题。最差的情况是:“不同的检查工具生成相同告警”。和scalastyle等相比,它有更多不同的检测项目。它们间不是冲突,而是互补。

scapegoat 有什么?

我们先看看scapegoat 有什么?即功能列表。

  • 从检查结果上分类,分为3类:通知、告警、错误。

  • 从类别而言,分为如下功能集:集合类使用、控制死循环检查、非空检查、异常处理、依赖导入、类型比较、引用检查、模式匹配、空指针检查、option检查、字符串检查、long转long等不需要操作检查、不安全操作检查、类型检查、命名规范、数学计算api检查、和其它杂项检查等17个功能集。

  • 从检查项上看,共检查117个项目。

可谓功能强劲,是否是人见人爱花见花开,另当别论。

scapegoat 如何用?

功能强大我们喜欢,易用才是真爱。那么,scapegoat如何配置使用哪?

开发环境的配置如下: - 离开背景谈使用,你是流氓嘛 ,^_^

IDEA: 2018.2.2版本
JDK:1.8+
SCALA: 2.11.8
SBT: 0.13.15

scape提供多种使用方法,我们使用添加sbt插件,而不是增加依赖库的方式。

  • 配置sbt插件依赖

    plugins.sbt中,加入依赖

addSbtPlugin("com.sksamuel.scapegoat" %% "sbt-scapegoat" % "1.0.0") 
  • 导入scapegoat配置依赖

    build.sbt导入配置,为了配置scapegoat关联的配置项(记住我们要用到该文件,后文做说明)

    import com.sksamuel.scapegoat.sbt.ScapegoatSbtPlugin.autoImport._
    scapegoatVersion in ThisBuild := "1.1.0" //配置项之一:指定版本
    
  • 如何触发代码分析和检查方法

和scalastyle实时显示编码问题不同,scapegoat是非实时的。即检查工具依赖在编译完成后,才能进行检查。scapegoat集成进DevOps非常方便,除了友好的呈现外,还它易于操作。

 ![IDEA terminal下检查方法:输入 scapegoat](https://upload-images.jianshu.io/upload_images/1655206-7ae5f9f20ba51903.PNG?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
scapegoat配置的那些事

项目化运作有时候是人性化运作。项目不同规范就千差万别,统一的规范满足不能调和所有人口味。我们就从配置的角度,来看看可做那些订制化。

  • scapegoat 配置列表
   //scapegoat默认配置列表
   scapegoatVersion := "1.0.0", //版本
    scapegoatRunAlways := true,
    scapegoatConsoleOutput := true,
    scapegoatVerbose := true,
    scapegoatMaxInfos := -1,
    scapegoatMaxWarnings := -1,
    scapegoatMaxErrors := -1,
    scapegoatDisabledInspections := Nil, //忽略的检查项
    scapegoatEnabledInspections := Nil,//激活检查项
    scapegoatIgnoredFiles := Nil, //忽略检查文件
    scapegoatReports := Seq("all"),
    scapegoatSourcePrefix := "src/main/scala")//源代码路径

上图是scapegoat的默认配置。前文提到配置在build.sbt完成。如果要进行个性化配置,自然也在其中配置。我们关注最多的是:检查哪些目录、检查结果目录设置。

//指定结果文件输出位置,就是忽略哪些些文件
scapegoatIgnoredFiles := Seq(".*/SomeScala*.scala")
//指定输出目录
scapegoatOutputPath := "/xiaozhaoying"
  • 高光时刻!!!

    工具使用时,总有那些时刻,不想让其发挥作用。总认为不是代码问题,而是工具检查“无理取闹”。所以,我们需要屏蔽那些错误。scapegoat提供了屏蔽上报问题的功能。当然,依然是注释类java.lang.SuppressWarnings功能支撑。

    class Test2 {
      @SuppressWarnings(Array("AsInstanceOf")) //`屏蔽不安全的asInstanceOf使用`
      def hello : Unit = {
        val s : Any = "sammy"
        println(s.asInstanceOf[String])
      }
    } 
    

到这里,配置部分和使用部分依然完成。它值得拥有简单易用标签。以下是呈现的哪些事。

结果在哪里?

scapegoat输出结果以XML的形式保存在 M:\xiaozhaoying\scapegoat.html中,呈现形式是这样:

scapegoat.png

根据xml输出结果相信:提升代码质量、规范化项目运作,不再是难事。即提升个人能力,又为项目运作效率。


最后

本文描述scapegoat特征、使用方式和配置管理等内容,和其它工具比起来是各有千秋。但检查工具化是项目运作必备的,文档规范约束是空谈,用起来是实干。

最后,有了scapegoat之后,誰是替罪羊(scapegoat)真不知道了。

江湖传闻,爱点赞也会赢。

你可能感兴趣的:(Scala style -静态代码分析工具 - “替罪羊”scapegoat)