纵向分析臃肿的Java依赖

原文标题：A longitudinal analysis of bloated java dependencies

原文作者：César Soto-Valero, Thomas Durieux, Benoit Baudry

原文链接：https://arxiv.org/pdf/2105.14226.pdf

发表期刊：ESEC/FSE’21

笔记作者：NING@SecQuan

笔记小编：ourren@SecQuan

1 研究介绍

软件开发不可避免的会引入或写入一些不必要、未使用的代码，这就是软件臃肿（bloated software）。这个现象已经出现许久，关于如何解决这个问题的研究也提出了很多，代表性的包括 JRed、 Slimium、RAZOR、Cimplifier、Trimmer等。而这些工作大多都是在不同细粒度上完成了去臃肿工作，而并没有从纵向（这里我理解的就是时间维度）的角度对软件膨胀问题进行分析。该方向的研究能够帮助我们看到整个 JAVA/Maven 生态中臃肿的依赖关系，同时能够看到整个生态的发展情况，并提示开发人员意识到去臃肿的重要性。

2 背景知识

Maven dependency：Maven 依赖，简单来说就是定义项目 A 和项目 B 的一种关系，例如 A 引入 B，就会在 A 中的 pom.xml 文件写入一个定位符 <groupId, artifactId, version>，如图 1 中 Figure 1所示。

Direct dependency：直接依赖，就是项目主 pom 文件中引入的依赖。

Transitive dependency：间接依赖，指的是直接依赖项目中引入的依赖。

Dependency tree：依赖树，项目依赖构建的一种树状结构，如图 1 中 Figure 2 所示。

Bloated dependency：臃肿依赖，存在与依赖树中，但是未被代码所使用的依赖，如图 1 中 Figure 3 所示。

Dependency usage status：依赖使用状态，在项目生命周期中依赖是否被使用的状态。

3 研究问题及结果

实验流程如图 3-1 所示，主要通过 collect、filter、analyze 三阶段完成纵向调研的流程。作者提出了 4 个问题来帮助引导调研方向。数据集主要包含筛选后的 435 个开源项目。

• RQ1：随着项目 Release 版本的迭代，其中臃肿依赖数目如何变化？

作者从 2011 年 1 月到 2020 年 11 月，每个项目中的臃肿依赖变化如图，发现直接依赖的臃肿比较平稳，而间接依赖中的臃肿不断增加。

• RQ2：项目中每个依赖随时间变化，依赖使用状态会发生哪些变化？

如图 3-3 所示，针对一个依赖的可能情况作者发现了 5 种可能情况。于是对其依赖的总体变化情况做了调查，结果如图 3-4 所示。

• RQ3：开发者会维护那些臃肿的依赖吗？

作者对比了开发人员和 Dependabot 在处理依赖更新上的情况。表明软件膨胀人为地增加了维护工作，并且依赖机器人需要改进以检测膨胀的依赖关系。

• RQ4：那些开发行为会改变依赖的使用状态呢？

作者发现大部分的臃肿还是源于新依赖的引入和代码的修改。

4 个人思考

• 当下既然存在 DepClean 这种工具，为什么还是存在许多冗余的依赖项呢？并且这方面的研究还是蛮多的，代码仓库应该推动冗余依赖的管理问题。

• 针对项目安全问题，可以使用该类工具帮助缩减项目大小，从而减小资源的使用。

• DecClean 工作原理主要基于静态检测，肯定有不足，检测不到的依赖问题。这可能会误报臃肿依赖的数目，作者也提到了这一点，但是作者认为这个对该项工作影响不大，但是感觉还是需要考虑一下。

• 未来臃肿处理工作可以使用动态分析，从而减少误报。