代码精简的治理方案和工具

一、前言

在大型软件系统中，随着业务的发展和变迁，部分代码线上已经废弃或者出现冗余，由于种种原因没有被及时删除和治理，随之而来的是代码维护成本提升。





代码精简的价值如上图所示，并由此成为服务治理的一个重要方向，在业界头部企业也有对应的治理项目谷歌【死神】项目，用机器人大规模删除代码：二十多年积累了数十亿行，已删除 5%C++ 代码, 其主要思路是通过程序自动识别代码否正在运行，并将识别结果和原因提交给工程师处理。

二、代码精简的整体解决方案





2.1 无效代码范围：

•无引用的变量、代码块、方法、类

•被注释的代码

•无流量的僵尸代码：已下线的功能、已被重构的历史代码等

2.2 治理思路：

•存量代码治理：采用关停并转（应用维度或者功能模块维度）、使用动态观测工具和静态分析工具识别无效代码和重复代码、代码重构等多个手段进行组合治理

•增量代码治理：利用jacoco+集成测试，识别增量代码的无效部分，随着集成测试case越来越丰富也可以辅助用来做存量代码治理与保障系统稳定性。superJacoco就是这种方案的代表产物，其背景是在实际项目测试过程中，case的设计经常会出现以下问题：

1.开发同学写了大量单测，一直重复执行一段代码逻辑，少数场景或异常代码逻辑并未执行到；

2.测试同学设计的测试用例经过反复评审，仍然有未覆盖到的异常场景，出现漏测情况；

3.接口自动化测试case作为日常回归手段，无法确定是否覆盖所有代码逻辑，其可靠性无法评估。

基于团队现状，应用集成jacoco并结合集成测试，可一举多得：

•沉淀的集成测试项目可用于后续保障应用稳定性

•集成测试单独触发的jacoco快照，可用于针对性的解决代码精简的范围

•检验测试用例的覆盖范围

单元测试是白盒测试，测试团队的自动化测试（系统测试）属于黑盒测试，集成测试介于两者之间属于灰盒测试。集成测试是保障服务稳定性的重要手段，最佳路径是TDD，需要建设对应的团队文化和工作流程。

2.3 方案简述：

笔者总结了如下5种方案用于代码精简的生产实践：

•利用 jacoco 观测线上代码覆盖情况

•APM产品观测代码块执行情况， UMP（京东内部自研传统报警监控系统）+Pfinder（京东内部自研全链路追踪产品，同SkyWalking）

•利用静态代码扫描识别无引用的变量、代码块、方法、类

•jacoco + APM产品组合观测线上流量 + 静态代码扫描

•集成测试 + jacoco 实现精准测试

长期来看，无效代码/重复代码识别可以往平台化/自动化的方向发展：

•平台化： 无侵入的收集代码覆盖率数据，和环境无缝对接，收集自定义时间段代码全量/增量覆盖率，并提供可视化报表，以及支撑精准测试落地。比如：Sonar（静态）、SuperJacoco

•自动化： 将冗余代码识别整合到 CI/CD 流程中，设置相应的审核/卡点机制。此环节比较出名的工具有：jenkins、hudson等，我们可以自定义行云流水线，和流水线原子来落地

三、 动态观测工具

3.1 使用Jacoco实现代码行级别的监控

通过JavaAgent方式无侵入的接入Jacoco，可监控到代码级别是否被执行的情况。参考资料 JaCoCo助您毁灭线上僵尸代码，共有3个工具：

•原生Jacoco接入

•京东行云流水线集成（二开Jacoco）

•滴滴开原方案Super-Jacoco

3.1.1 原生Jacoco接入

1.在工程内的pom中引入jar依赖

<dependency>
    <groupId>org.jacoco</groupId>
    <artifactId>org.jacoco.ant</artifactId>
    <version>0.8.3</version>
</dependency>
<dependency>
     <groupId>org.apache.ant</groupId>
     <artifactId>ant</artifactId>
     <version>1.9.9</version>
 </dependency>

1.在工程内增加http接口，用于通过ant执行dump task生成Dump Coverage文件

@RestController
@RequestMapping("/coverage")
public class CoverageController {

    @PostMapping("dump")
    @NoCheckMenuPermission
    public Result<Boolean> dumpCoverageFile() {
        DumpTask dumpTask = new DumpTask();
        // dump文件地址
        dumpTask.setDestfile(new File("/xxxxx/xxxxx/coverage/code-cover.exec"));
        // 多次dump追加形式
        dumpTask.setAppend(true);
        // 选一个空闲接口即可
        dumpTask.setPort(8800);
        // 默认本机
        dumpTask.setAddress("127.0.0.1");
        dumpTask.execute();
        return Result.succeed(true);
    }
}

1.程序启动引入jacoco 的 javaAgent

在服务端需要jacocoagent增强的jar包，获取方式有两种：

•在服务端中解压org.jacoco.agent这个jar 获取 jacocoagent

jar -xvf $BASEDIR/lib/org.jacoco.agent-0.8.3.jar

•直接将jacocoagent 上传至oss, wget命令拉取到服务本地

wget "http://storage.jd.local/bpp-quality-public/code_coverage_statistics/jacoco-0.8.7-20210115.151120-42.tar.gz"

java 应用启动添加如下参数：

includes 为需要监控的代码包路径

-javaagent:$BASEDIR/bin/jacocoagent.jar=includes=com.jdwl.*,output=tcpserver,port=8840,address=127.0.0.1 -Xverify:none

1.dump文件分析

请求应用 "coverage" http接口，并下载 "code-cover.exec" 文件到本地，打开idea -> run -> show coverage data选择对应的exec文件即可获取服务端的代码覆盖情况。效果如下图所示：



















缺点：

•源码层面集成（maven依赖、HTTP接口触发数据采集）

•没有体现代码执行频次/执行时间

•监控数据是单机的，没有全局看板

•线上发布较长时间后结合代码实际执行命中情况进行清理

优点：

•不需要侵入业务代码，可识别到代码行级别是否被执行到

3.1.2 京东行云流水线集成





原子输出如下：













缺点：

•没有体现代码执行频次/执行时间

•线上发布较长时间后，结合代码实际执行命中情况进行清理

优点：

•对比原生Jacoco接入，无需源码层面集成（比如：maven依赖、HTTP接口触发数据采集）

•监控数据是全局看板（可以配置多个IP进行采集合并）

•不需要侵入业务代码，可识别到代码行级别是否被执行到

3.1.3 滴滴开源方案 Super-Jacoco

开源工具：https://github.com/didi/super-jacoco/tree/master#readme

Super-Jacoco是基于Jacoco、git二次开发打造的一站式JAVA代码全量/diff覆盖率收集平台，能够低成本、无侵入的收集代码覆盖率数据；Super-Jacoco除了支持JVM运行时间段的覆盖率收集外；还能够和环境无缝对接，收集服务端自定义时间段代码全量/增量覆盖率；并提供可视化的html覆盖率报表，协助覆盖率分析，支撑精准测试落地。

•无需对开发代码做任何改造，只需在服务启动命令中添加javaagent即可。

•依托于Super-Jacoco，基于Jacoco、Git二次开发，收集两个版本间增量代码差异。

•用户执行测试用例，用例执行过程中Jacoco会记录代码覆盖情况。

•生成可视化的HTML覆盖率报告，协助用例覆盖情况精准分析。





部署参考文档：https://blog.csdn.net/meifannao789456/article/details/121738716

缺点：没有体现代码执行频次/执行时间，但用于精准测试场景，可不用关心这两个问题。

3.2 使用APM产品观测

使用APM产品（Application performance monitoring，应用程序性能监控）对应用流量入口（HTTP，JSF，MQ）或者代码块维度进行监控，筛选出一定时间内没有流量的代码进行治理，为提高效率可结合静态代码分析工具，清理无引用的的代码。

HTTP流量观测

可使用UMP、PFinder来观测

JSF流量观测

可根据业务现状，利用UMP、泰山JSF流量观测 、PFINDER、SideCar 对JSF流量进行监控。推荐JSF流量观测，无须接入，效果如下，可具体到方法层面流量情况，并能反应客户端信息：





MQ流量观测

可根据业务现状，利用UMP、PFINDER、SideCar 对MQ流量进行监控，推荐SideCar方案wormhole https://taishan.jd.com/wormhole/overview , 无侵入，无MQ版本限制，且接入成本低。

3.2.1 UMP（监控报警）

监控粒度：可以通过编码方式最小监控到代码块级别，目前主要应用于方法级别的监控

接入方式：集成UMP SDK，需要编写代码实现对关注业务的监控，多应用于一般业务代码、AOP切面

可监控范围：可通过多种形式的代码集成方式，可对任意维度流量进行监控

优点：可控性强，很灵活，存量应用大部分已接入

缺点：有一定代码耦合度，增量观测需要编写代码

3.2.2 PFinder(全链路追踪)

监控粒度：最小可以通过编码方式监控到代码块级别，在全链路追踪中，最小的可观测单元是span(跨度)，目前默认情况下pfinder的span主要用于定义跨容器通信的网络节点。

接入方式：有两种方式，

•通过javaAgent方式无侵入的集成，最小只能监控到方法级别

•通过javaAgent + SDK 的方式集成，通过编码方式最小可监控到代码块级别，但是每个应用的自定义SPAN有数量限制, 示例如下：

//自定义metric
public static final MetricPlan<Histogram> TIMED_PLAN = PfinderContext.getMetricRegistry()
            .histogram("XXXXXXXX")
            .tagKeys("client_sign") //
            .build();

MethodExecutionWatcher watcher = PFinderUtils.TIMED_PLAN.ofTagValues(new String[]{"newPop"}).watcher();
try{
  ....
} catch (Exception e) {
   watcher.fault();
   throw e;
} finally {
   watcher.close();
}

效果如图：





可监控范围：可通过监控代码耦合和注解方式进行集成，可对HTTP,JSF,MQ,数据库等流量进行监控

优点：有一定灵活性，全链路追踪trace上默认有很多关键span，可自定义metric, 存量应用大部分已接入

缺点：代码块观测需要编写代码，有一定代码耦合度，且自定义span有数量限制

3.2.3 SideCar

公司内部已整体采用了 kubernetes 作为 容器编排 paas底座，并参考Istio 自研了SideCar容器产品wormhole https://taishan.jd.com/wormhole/overview，可用于应用观测、服务治理、混沌演练。

监控粒度：东西流量网络端点——JSF接口/MQ/http，HTTP由于数据规模过大，目前只存储到POD端口级别的监控数据

接入方式：利用k8s 服务编排，无侵入接入业务系统，由于公司内部k8s版本问题，部分分组不支持





可监控范围：JSF接口/MQ ，监控示例如下：









优点：无侵入，以应用为中心的观测方式比较全面

缺点：JSF监控粒度到接口级别，HTTP监控到端口级别

四、 静态分析工具

借助IDEA自带的代码审查功能、PMD、SonarLint等工具对代码进行静态检测，从代码精简的角度出发，可以识别的问题如下：

•DEAD CODE（僵尸代码识别）

•REPEAT CODE （重复代码）



利用静态分析工具寻找悬挂引用点，这种方案的缺陷：

•无法找到通过反射机制得到的引用点。

•存在继承体系的情况下，静态扫描无法有效识别悬挂引用点。



4.1 IDEA自带的代码审查功能

idea代码审查官方文档

IntelliJ IDEA 具有强大、快速和灵活的静态代码分析功能。可以发现多种情况的代码效率低下。每当你遇到一些无法访问的代码、未使用的代码、非本地化的字符串、未解决的方法、内存泄漏甚至拼写问题 - 你就会发现代码检查很有用。

4.1.1 示例





代码审查相关功能在Code菜单这里（如下图）。两条灰色的线条将这几项归为一类：











点击OK运行，在problem视窗里可以看到“有问题”的代码：





经过审查，本工程里的“坏味道”代码就在problem视窗指出了。如图，IDEA针对性的提供了便捷的一键处理按钮，你可以快速处理， IDEA 静态扫描问题清单 。



自动检查清除冗余资源

自动检查清除冗余资源详细功能Name对应Idea中Preferences—>Editors—>Inspections中所有内容

1、清理无效类 Run Inspection by Name：Empty Class





2、查看未使用方法 Run Inspection by Name：Unused declaration

包含了项目里面声明了没用使用过的变量,方法和类

对于检测的内容，idea提供四种解决方案





3、查看类中有未使用引用 Run Inspection by Name：Unused import





IntelliJ IDEA 搜索重复项

1.执行以下操作之一：

◦在主菜单上选择 分析| 查找重复项（Analyze | Locate Duplicates）。

◦在编辑器或项目工具窗口的上下文菜单中选择分析|找到重复命令（Locate Duplicates）。

2.在 "指定代码复制分析范围" 对话框中，指定分析范围（整个项目、当前文件、未提交的文件（对于版本控制下的项目）或某些自定义范围）。此外，您还可以将测试源包含在分析中。

3.单击“确定”，准备就绪。

4.在“代码复制分析设置”对话框中，请执行以下操作：单击“确定”。

1.选择要在其中执行分析的语言。

2.对于每种语言，请检查选项以定义分析的首选项。

3.例如，您可以选择请求相同的代码片段匹配被视为重复项，或者指定一个特定的限制，以下的代码结构不被认为是重复的（以避免报告if源代码中的每个构造）。

5.在“重复”工具窗口，浏览搜索结果。





•在工具窗口的左窗格中查看重复项列表。

•查看右窗格中找到的重复项之间的差异。使用箭头按钮将所选副本放在差异查看器的其中一个部分，并比较代码片段。

•导航到编辑器中的重复项，使用“跳转到源”或“显示重复上下文”菜单的源命令。

•通过单击并在 "提取方法" 对话框中指定方法名称和参数来消除源代码中的重复项。这个程序类似于提取方法重构，唯一的区别是，在重复分析的情况下，重复的代码块被自动找到。

IntelliJ IDEA 动态检测重复项

IntelliJ IDEA 可以动态查找重复的内容。这是由检查 一般| 重复的代码（（General | Duplicated Code））。

如果您偶然发现一个现有的副本，或者通过编写或粘贴代码创建一个副本，您将立即知道：





检查伴随着快速修复，它使您能够导航到检测到的重复项，或在 "查找工具" 窗口中查看所有这些副本：





请注意，IntelliJ IDEA 有助于避免在生成的源中找到重复项。

为此，选中该复选框可忽略在 "检查设置" 页中标记为 "生成的源" 中的重复代码：





代码审查的策略

IDEA怎么知道这是坏味道代码的？遵照什么规则？显然，一切都是“有法可依”，它在这：设置 -> Editor -> Inspections





4.2 PMD（Programming Mistake Detector）

PMD 侧重面向安全编码规则，且具备一定的数据流分析和路径分析能力，能力比 CheckStyle 稍微强点，并且 PMD 支持自定义规则，PMD 可以直接使用的规则包括以下内容：

•未使用的代码（Dead code） ：未使用的变量、参数、私有方法等

•复杂的表达式：不必须的 if 语句、可被 while 替代的 for 循环

•重复的代码：拷贝/粘贴代码意味着拷贝/粘贴 bugs

•循环体创建新对象：尽量不要在循环体内实例化新对象

4.2.1 IDEA插件

安装步骤

IDEA通过 File > Settings > Plugins > Marketplace 搜索 “PMD”，按照提示进行安装，然后重启即可

配置检测规则

通过 File > Settings > Other Settings > PMD 可以打开检测规则的设置界面：





在 “RuleSets（规则设置）” 界面可以管理自定义的检测规则。因为在实际工作中，可能需要根据实际情况自定义检测规则，就可以通过这里导入，如果要使用它，需要在启动 PMD 进行检测时选择该自定义规则。

点击“Options”选项卡，在其中可以配置一些检测规则选项：





其中重点需要留意的是“Skip TestSource”这一项，选择上述选项后可以将其过滤掉。

运行方式

（1）从 Tools 菜单中启动：

通过 Tools > Run PMD 可以看到如下的界面，如果通过该方式启动，扫描的范围就是整个项目中的文件了。





•Pre Defined：预定义的规则，也就是插件自带的检测规则。后面展开的列表中列出了所有的规则列表，想扫描哪一种类型的问题，点击即可。其中“All”表示使用所有的规则。

•Custom Rules：自定义的检测规则，PMD 允许用户根据需要自定义检查规则，默认这里是不可点击的，需要在设置中导入自定义规则文件后方可选择。

（2）从右键菜单中启动：

在文件或者编辑器中点击右键，也可以看到“Run PMD”选项，如果通过该方式启动， 检测范围取决于鼠标或光标当前所选中的区域。

运行结果





运行后会出现如上所示的面板，左边工具栏，鼠标停留在上面会提示其功能；右边显示了检测结果，当点击具体某一问题项时，会跳转到对应的源码中。







4.2.2 Maven插件

Maven提供了PMD项目报告插件，能让用户生成静态代码分析审查报告

POM配置：

<project>
    ...
    <reporting>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-pmd-plugin</artifactId>
                <version>3.21.0</version>
                <configuration>
                    <rulesets>
                        <ruleset>/rulesets/java/braces.xml</ruleset>
                        <ruleset>/rulesets/java/naming.xml</ruleset>
                    </rulesets>
                </configuration>
            </plugin>
        </plugins>
    </reporting>
</project>

执行PMD检查：

mvn site

生成的文件为 target/site 目录下的 pmd.html 文件





Files

com/baeldung/pmd/Cnt.java

Violation                                                                             Line

Avoid short class names like Cnt                                   1–10 
Avoid using short method names                                  3 
Avoid variables with short names like b                        3 
Avoid variables with short names like a                        3 
Avoid using if...else statements without curly braces 5 
Avoid using if...else statements without curly braces 7 



4.3 SonarLint

Sonar 不仅关注常规静态 BUG，还关注到了如代码质量、包与包、类与类之间的依赖情况，代码耦合情况，类、方法、文件的复杂度，代码中是否包含大量复制粘贴的代码，关注的是项目代码整体的健康情况。sonar 有两种使用方式：插件和客户端，sonar 的插件名称为 sonarLint，可用于集中式卡点。

安装步骤

通过 File > Settings > Plugins > Marketplace 搜索 “SonarLint”，按照提示进行安装，然后重启即可

使用说明





右键项目或者文件进行如上图所示操作，执行之后可以看到如下信息，如果代码中有不合理的地方会在 report 中显示，同时点击错误的地方在右边会给出建议的修改供参考。





配置 SonarLint 服务端

配置 Sonar 服务器

sonarLint 插件的使用场景是自用自审，但 sonar 也提供了平台版本，使用场景则是他审，sonar 平台的搭建就不在这篇文章介绍了，感兴趣的读者可以自己上网查看，我们这里主要介绍如何在 sonarLint 插件中配置关联 sonar 平台服务器的工程，进行本地检查：





点击新增按钮，输入Configuration Name，配置sonarlint 服务器的地址，然后下拉框选择 Login/Password，输入 sonarlint服务器的账号密码





具体 Sonar 工程配置

配置完服务器之后，需要针对具体工程进行配置，点击 connection下拉框，选择上面配置好的服务器连接，然后点击 Search in list，找到对应的工程：





使用 SonarLint 检查

配置完上面两步之后，接下来就可以选择要进行检查的类或者目录进行 sonarlint 检查了（跟第 3 点的使用方式一致），同时，在 commit 代码的时候，勾选 “Perform Sonarlint analysis”，会针对你要提交的代码进行 sonarlint 检查