代码精简的治理方案和工具
一、前言
在大型软件系统中，随着业务的发展和变迁，部分代码线上已经废弃或者出现冗余，由于种种原因没有被及时删除和治理，随之而来的是代码维护成本提升。
代码精简的价值如上图所示，并由此成为服务治理的一个重要方向，在业界头部企业也有对应的治理项目谷歌【死神】项目，用机器人大规模删除代码：二十多年积累了数十亿行，已删除 5%C++ 代码, 其主要思路是通过程序自动识别代码否正在运行，并将识别结果和原因提交给工程师处理。
二、代码精简的整体解决方案
2.1 无效代码范围：
2.2 治理思路：
1.开发同学写了大量单测，一直重复执行一段代码逻辑，少数场景或异常代码逻辑并未执行到；
2.测试同学设计的测试用例经过反复评审，仍然有未覆盖到的异常场景，出现漏测情况；
3.接口自动化测试case作为日常回归手段，无法确定是否覆盖所有代码逻辑，其可靠性无法评估。
基于团队现状，应用集成jacoco并结合集成测试，可一举多得：
单元测试是白盒测试，测试团队的自动化测试（系统测试）属于黑盒测试，集成测试介于两者之间属于灰盒测试。集成测试是保障服务稳定性的重要手段，最佳路径是TDD，需要建设对应的团队文化和工作流程。
2.3 方案简述：
笔者总结了如下5种方案用于代码精简的生产实践：
长期来看，无效代码/重复代码识别可以往平台化/自动化的方向发展：
三、 动态观测工具
3.1 使用Jacoco实现代码行级别的监控
通过JavaAgent方式无侵入的接入Jacoco，可监控到代码级别是否被执行的情况。参考资料 JaCoCo助您毁灭线上僵尸代码，共有3个工具：
3.1.1 原生Jacoco接入
<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>
@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);
}
}
在服务端需要jacocoagent增强的jar包，获取方式有两种：
jar -xvf $BASEDIR/lib/org.jacoco.agent-0.8.3.jar
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
请求应用 "coverage" http接口，并下载 "code-cover.exec" 文件到本地，打开idea -> run -> show coverage data选择对应的exec文件即可获取服务端的代码覆盖情况。效果如下图所示：
缺点：
优点：
3.1.2 京东行云流水线集成
原子输出如下：
缺点：
优点：
3.1.3 滴滴开源方案 Super-Jacoco
开源工具：https://github.com/didi/super-jacoco/tree/master#readme
Super-Jacoco是基于Jacoco、git二次开发打造的一站式JAVA代码全量/diff覆盖率收集平台，能够低成本、无侵入的收集代码覆盖率数据；Super-Jacoco除了支持JVM运行时间段的覆盖率收集外；还能够和环境无缝对接，收集服务端自定义时间段代码全量/增量覆盖率；并提供可视化的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主要用于定义跨容器通信的网络节点。
接入方式：有两种方式，
//自定义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等工具对代码进行静态检测，从代码精简的角度出发，可以识别的问题如下：
利用静态分析工具寻找悬挂引用点，这种方案的缺陷：
4.1 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 搜索重复项
if源代码中的每个构造）。
IntelliJ IDEA 动态检测重复项
IntelliJ IDEA 可以动态查找重复的内容。这是由检查 一般| 重复的代码（（General | Duplicated Code））。
如果您偶然发现一个现有的副本，或者通过编写或粘贴代码创建一个副本，您将立即知道：
检查伴随着快速修复，它使您能够导航到检测到的重复项，或在 "查找工具" 窗口中查看所有这些副本：
请注意，IntelliJ IDEA 有助于避免在生成的源中找到重复项。
为此，选中该复选框可忽略在 "检查设置" 页中标记为 "生成的源" 中的重复代码：
代码审查的策略
IDEA怎么知道这是坏味道代码的？遵照什么规则？显然，一切都是“有法可依”，它在这：设置 -> Editor -> Inspections
4.2 PMD（Programming Mistake Detector）
PMD 侧重面向安全编码规则，且具备一定的数据流分析和路径分析能力，能力比 CheckStyle 稍微强点，并且 PMD 支持自定义规则，PMD 可以直接使用的规则包括以下内容：
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 可以看到如下的界面，如果通过该方式启动，扫描的范围就是整个项目中的文件了。
（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 检查
