技术债务 (TD) 是一个成功的隐喻，可以将软件效率低下的后果及其消除传达给技术和非技术利益相关者，这主要是由于其货币性质。 TD 的识别和量化在很大程度上依赖于少数复杂工具的使用，这些工具通常通过静态分析来检查是否违反了某些预定义规则。不同的工具会导致不同的 TD 估计，从而质疑单一工具得出的结果的可靠性。为了缓解这个问题，我们使用与每个类的源代码、存储库活动、问题跟踪、重构、重复和评论率有关的 18 个指标作为统计和机器学习模型的特征，以便将它们分类为高 TD 与否。作为基准，我们利用从 25 个 Java 项目中获得的 18,857 个类，其高水平的 TD 已被三个领先工具证实。研究结果表明，以足够的准确度和合理的努力来识别 TD 问题是可行的：高级分类器的子集实现了大约 0.79 的 F2 测量分数，相关的模块检查率大约为 0.10。基于结果，实现了用于自动评估 Java 项目 TD 的工具原型。

1 INTRODUCTION

技术债务 (TD) 是一个隐喻，在涉及提高软件质量的投资时，促进了技术和非技术利益相关者之间的讨论 [1]。与金融债务一样，由于设计和实施选择有问题而积累的 TD 需要在软件开发生命周期中尽早偿还。如果不这样做，那么它可能会以难以偿还的未来成本增加的形式产生利息支付。在这种情况下，软件项目的开发可能会因 TD 的存在而受到严重阻碍：软件公司因 TD 而浪费的精力可能高达开发人员总时间的 23% [2]，在极端情况下甚至可能导致无法维护的软件产品，从而导致技术破产 [3]。因此，应应用适当的 TD 管理，以识别、量化、优先排序和偿还 TD 问题。然而，在整个软件开发生命周期中管理 TD 是一项具有挑战性的任务，需要适当的工具。最近的一项研究 [4] 揭示了 26 种有助于识别、量化和偿还 TD 的工具。用于识别 TD 问题的策略不同，但最常用的方法依赖于可以通过静态源代码分析断言的预定义规则：任何违反规则都会产生 TD 问题，而解决问题的估计时间有助于整体 TD 主体.由于它们的规则集不同，这些工具的结果都不能被视为最终的预言 [5]，而使用多个工具来聚合它们的结果不是一个可行的解决方案，因为：(a) 出于相同的原因执行多个工具可以被视为资源浪费； (b) 没有明确的合成方法； (c) 获得多种专有工具不具有成本效益。

上述缺点导致了重要问题：一方面，学术努力面临严重的结构有效性问题，因为无论用于识别技术债务项目 (TDI) 的工具如何，如果结果是否相同，总是存在疑问。使用了不同的工具基础设施。另一方面，对于行业而言，通常发现的问题清单很长，从业者在众多的建议中迷失了方向。最重要的是，他们面临一个决策问题：“我应该信任哪种工具来识别/量化 TD？”。作为缓解上述问题的第一步，在之前的研究 [5] 中，我们通过 SonarQube [6]、CAST [7] 和 Squore [8] 三种广泛采用的工具分析了 TD 评估，目的是评估程度它们之间的一致性，并建立一个经验基准（TD Benchmarker 1）共享相似水平的 TD 的类/文件。该研究的结果（除了基准本身）证实，不同的工具最终用于对 TD 的不同评估，但在某种程度上，它们集中在识别表现出高水平 TD 的类别上。

鉴于上述结果，在本文中，我们建议使用统计和机器学习 (ML) 模型对 TD 类（高/非高 TD）进行分类。作为所提出的分类框架的基本事实，我们使用通过在 25 个 OSS Java 项目上应用 TD-Benchmarker 获得的数据集，并将所有工具识别为 TDI 的类分类为高 TD。然后，假设使用多种信息源将产生更准确的模型，我们基于从代码相关指标到捕获开发过程各个方面的指标的广泛软件特征构建了一组自变量，检索到通过开源工具。最后，我们应用各种统计和 ML 算法，以便为给定问题选择最合适的算法。最终，派生模型包含了通过结合三个 TD 工具的结果提取的集体知识，利用“公认的 TD 知识库”[5]。为了便于在实践中采用，这些模型已作为工具原型实现，该原型依赖于其他开源工具来自动检索所有自变量并识别任何软件项目的高 TD 类。

本文的主要贡献总结如下：

i) 对各种统计和机器学习算法检测高 TD 软件类的能力进行实证评估；

ii) 执行分类时要考虑的一组因素，从代码指标到存储库活动，由开源工具检索；

iii) 一个工具原型，通过指向其 git 存储库为任意 Java 项目生成已识别的高 TD 类。

2 RELATED WORK

TD 是软件质量的一个指标，强调可维护性。在过去的几年中，大量的研究涉及软件可维护性预测方面，通常采用 ML 回归技术 [9]、[10]、[11]。然而，通过我们在相关文献中的搜索，我们无法确定关于 ML 在将软件模块分类为高 TD 与否方面的适用性的具体贡献。另一方面，大量研究采用分类技术来预测与 TD 概念直接或间接相关的各种质量方面，例如代码异味、更改倾向、缺陷倾向和软件重构。

代码异味被认为是 TD [12] 的关键指标之一。最近，在文献 [13]、[14]、[15]、[16] 中提出了大量与代码气味检测相关的工作。这些研究中的大多数评估了不同的机器学习分类器在检测各种类型的代码异味的任务上，并得出结论，通过正确的优化，机器学习算法可以获得良好的性能。然而，在自变量的选择、ML 算法或训练策略方面仍有改进的空间 [17]。除了代码异味，软件更改倾向和缺陷倾向也是流行的 TD 指标；易于更改的模块往往会产生更多的缺陷并积累更多的 TD [18]。迄今为止，各种研究已经研究了 ML 分类器在识别变化和易缺陷模块方面的适用性 [18]、[19]、[20]、[21]。然而，由于这些贡献是有限的并且受到外部有效性威胁[22]，研究人员应该对这些方向进行进一步的探索。最后，TD 与软件重构密切相关，因为后者是在现有源代码上减少它的唯一有效方法。然而，研究人员最近才开始探索如何使用 ML 来帮助识别重构机会 [23]。

从上述文献分析中可以清楚地看出，ML 分类方法虽然尚未检查其识别 TD 本身存在的能力，但已被广泛用于尝试准确建模各种 TD 相关问题。更重要的是，这些研究在它们采用的分类框架方面存在许多相似之处。为了突出这些相似之处，表 1 概述了这些研究中做出的关键决策，包括它们的实验设置。关于所采用的分类算法，可以看出逻辑回归 (LR)、朴素贝叶斯 (NB) 和随机森林 (RF) 是迄今为止使用最广泛的分类器，其次是支持向量机 (SVM) 和决策树（DT）。其他研究还使用 J48、eXtreme Gradient Boosting (XGB) 和 K-Nearest Neighbor (KNN) 等。在性能方面（以粗体突出显示），随机森林似乎是最有效的算法之一。关于模型训练和验证策略，10 倍交叉验证是每个报告研究中使用的事实上的方法。值得一提的是，除了交叉验证之外，只有一项研究 [14] 使用保留集在完全看不见的数据上测试生成的模型。在模型参数优化方面，Grid Search 是最常用的方法，其次是 Random Search。最后，就性能评估而言，Precision 和 Recall 几乎在所有报道的研究中都会用到，而 FMeasure 和 ROC Curve 也很受欢迎。

为了设计在这项工作的背景下提出的实验研究，我们采用了一些关于模型选择、模型配置和性能评估的最常见做法。更多细节可以在第 3.3 节中找到。

3 METHODOLOGY

在本节中，我们介绍了整个研究过程中遵循的方法。该方法包括三个阶段：（i）数据收集，（ii）数据准备（预处理和探索性分析），以及（iii）模型构建。我们注意到，在本文档的其余部分中，我们将使用术语“模块”来指代软件类，以避免将软件与分类类混在一起使读者感到困惑。

3.1 Data Collection

3.1.1 Project Selection and Dependent Variable

本研究的数据集基于在 Amanatidis 等人的研究背景下构建的经验基准。 [5]。该研究的目的是评估领先的 TD 评估工具之间的一致性程度，通过提出一个框架来捕捉所检查工具的多样性，从而确定代表模块特征案例的配置文件相对于它们的 TD 水平。为此，他们利用SonarQube（v7.9，2019）、CAST（v8.3，2018）和Squore（v19.0，2019）三种流行的TD评估工具构建了一个基准数据集，用于分析25 个 Java 和 25 个 JavaScript 项目，然后提取与所选配置文件相似的模块集（例如，所有使用的工具中的高 TD 级别）。

本研究的主要目标是训练有效的统计和 ML 技术来识别高 TD 级别的模块，即生成预测属于 Max-Ruler 类配置文件的模块的模型。 Max-Ruler 类配置文件，由 Amanatidis 等人定义。 [5]，是指基于树应用工具的结果，其参考评估类型表明大量 TD 的模块。我们专注于使用 Java 开发的项目，因为我们用于扩展数据集的大多数工具只能应用于 Java 应用程序。就像 Amanatidis 等人的工作一样。 [5]，我们分析了相同的 25 个项目，将它们的模块视为分析单元。表 2 中详细介绍了这些项目。根据作者 [5]，选择它们的标准是编程语言（即 Java）、它们在 GitHub 中的公共可访问性、它们的受欢迎程度（超过 3 K 星），最后是，他们的积极维护直到研究的时间。

包含 25 个 Java 项目的每个模块的三个工具的 TD 评估的数据集在 Zenodo 2 上以 Excel 文件的形式公开提供。每个项目的 Max-Ruler（即高 TD）模块可以从 TD Benchmarker 3 以 csv 文件的形式获得。为了开始构建整个研究中使用的数据集，我们首先下载了包含正在检查的 25 个 Java 项目的所有模块的 Excel 文件，然后，对于每个项目，我们下载了仅包含高 TD 模块的 csv 文件。随后，我们将高 TD 模块实例与初始 Excel 文件（包含所有模块）合并，并将高 TD 模块标记为“1”。其余模块标记为“0”。这个过程产生了一个包含 18,857 个模块的数据集；其中 1,283 个属于 Max-Ruler 配置文件（即高 TD 模块）。

3.1.2 Analysis Tools and Independent Variables

为了构建高效的分类模型，我们需要研究各种指标（从重构操作到流程指标，从代码问题到源代码指标）有效区分高 TD 模块实例和非高 TD 模块实例的能力。因此，为了构建我们的数据集，我们使用了一组工具，这些工具可以分为两大类：计算进化属性的工具（即跨整个项目演化）和计算与单个相关的指标（即最新的）犯罪。

最初，通过使用两个广泛使用的 OSS 工具，即 PyDriller [24] 和 RefactoringMiner [25]，计算了 25 个选定 Java 项目的每个模块的演化指标。更具体地说，PyDriller (v1.15.5, 2021)，即用于挖掘 Git 存储库的 Python 框架，用于计算模块级 Git 相关指标，例如提交计数、代码流失和贡献者在整个演进过程中的经验的项目。随后，RefactoringMiner (v2.0.3. 2020) 是一种基于 Java 的工具，能够检测 55 种不同类型的重构，被用来计算每个模块在整个演进过程中的重构总数。除了上述两个工具之外，Jira 和 GitHub 问题跟踪器 API（取决于项目）还用于获取与所选项目的每个模块相关的问题总数，在其整个演变过程中。

除了用于计算进化指标的工具外，还考虑了三个额外的工具，即 CK [26]、PMD 的复制/粘贴检测器 (CPD) 4 和 cloc 5，用于计算与每个模块的最新提交相关的指标。更具体地说，CK (v0.6.3, 2020) 是一种通过静态分析计算 Java 项目中类级别指标的工具，用于计算各种 OO 指标，例如每个模块的 CBO、DIT 和 LCOM。随后，CPD (v6.30.0, 2020) 是一种能够在包括 Java 在内的各种编程语言中定位重复代码的工具，用于计算每个模块的重复行总数。最后，cloc (v1.88, 2020) 是一个开源工具，能够计算许多编程语言中的注释行和源代码行，用于计算每个模块的代码和注释行总数。

为了训练能够识别高 TD 模块的有效分类模型，我们需要研究什么样的指标（或指标集）与模块是否具有高 TD 密切相关。然而，正如许多研究 [27] 中所述，软件系统中 TD 的增长与系统本身的增长有关，即系统规模越大，其 TD 值越大。因此，为了排除模块的 TD 级别仅因为模块的大小而与度量相关的可能性，我们对两个度量进行了归一化以控制大小的影响。通过这种转换的第一个度量是重复线，在除以每个模块的 ncloc 度量后，被重命名为重复线密度。此外，注释行指标也进行了标准化，但不是除以代码行，而是除以每个模块的代码和注释行（ncloc + 注释行）之和。随后，注释行度量重命名为注释行密度。

应该注意的是，针对 55 种不同的重构类型（由 RefactoringMiner 标识）中的每一种单独考虑检测到的重构操作的数量可能会导致变量数量的不必要增加，从而导致后期阶段的复杂性增加（即，在模型训练期间）。此外，通过检查 RefactoringMiner 结果，我们发现对于大多数模块，大多数重构类型的重构操作数量为零，因此可能导致在数据集中添加相对较大的稀疏矩阵。因此，我们决定将每个模块的重构操作数汇总为一个称为总重构的新指标。此指标计算在演进期间在模块中执行的重构操作总数（针对所有 55 种重构类型）。

在表 3 中，我们展示了在 25 个 Java 项目的每个模块的数据收集步骤中评估的指标，以及简短的描述。

因此，最终数据集包含一个包含 18,857 行（分析模块的数量）和 19 列的表，其中前 18 列中的每一列都包含特定指标的值，而表末尾的额外列包含Max-Ruler 的值（类）（即，模块是否具有高 TD）。由于本研究的目标是调查各种指标（代码、人员或流程相关）与模块是否具有高 TD 的关系，并随后训练有效的 ML 模型来识别高 TD 模块，因此参考的列metrics 将扮演自变量的角色，而最后一列引用 Max-Ruler 类将扮演因变量的角色，即我们试图预测的模块 TD 级别。这种格式在第 3.3 节中描述的分类模型构建阶段帮助了我们。

3.2 Data Preparation

3.2.1 Data Pre-processing

在提取每个项目的模块级指标（使用六个工具）并将它们合并到第 3.1 节所述的公共数据集后，我们继续进行适当的数据预处理任务，其中包括缺失值处理和异常值检测技术。

从缺失值处理开始，我们观察到在某些情况下 CK 工具无法运行，因此无法计算特定模块的指标。更具体地说，在总共 18,857 个模块中，CK 工具生成了 18,609 个的结果，这意味着跳过了 248 个模块。由于这个数字相对较小（占数据集的 1.3%），我们决定不继续进行数据插补以替换缺失值，而是删除包含缺失值的实例。这产生了一个包含 18,609 个模块的新数据集，该数据集略小但同样具有代表性。

通过快速检查我们的数据，我们注意到所有自变量都呈现出偏态分布，并带有许多极值。因此，在执行缺失值删除后，我们继续进行异常值检测。异常值是极端值，通常可能导致数据探索过程中的测量错误或 ML 模型训练期间的预测性能不佳。 ML 建模和模型技能通常可以通过理解甚至移除这些异常值来提高 [28]、[29]。在样本中值的分布是高斯（或类高斯）分布的情况下，样本的标准差可以用作识别异常值的截止值。然而，在我们的例子中，指标的分布是倾斜的，这意味着没有一个指标遵循正态（高斯）分布。因此，我们使用了一种称为局部异常值因子 (LOF) [30] 的自动异常值检测技术。 LOF 是一种尝试利用最近邻的概念进行异常值检测的技术。每个样本都根据其本地邻域的大小被分配一个评分，即它的孤立程度或成为异常值的可能性有多大。得分最高的样本更有可能是异常值。将 LOF 应用于数据集会生成一个包含 17,797 个模块的新数据集，这意味着由于算法将它们标记为异常值，因此删除了 812 个模块。

最终数据集的变量的描述性统计数据如表 3 所示。此时应注意，在未应用上述异常值检测的情况下，也对所选分类器的性能评估进行了调查，如稍后将在第 4 节中介绍的那样和删除步骤。然而，正如预期的那样，不去除极值会导致性能指标变差，因此，我们继续执行本节所述的异常值去除步骤。

3.2.2 Exploratory Analysis

探索性分析过程中的一个重要步骤是检查所选指标之间是否存在可观察到的关系以及构建数据集的高 TD 和非高 TD 模块的存在。为此，我们使用假设检验和单变量逻辑回归分析研究了所选指标的判别能力和预测能力，本节其余部分将对此进行详细描述。

为了确定选定的 18 个指标区分高 TD 和非高 TD 模块的能力，我们测试了高 TD 和非高 TD 模块的每个指标的分布相等的零假设。由于指标是倾斜的并且具有不相等的方差（参见表 3），我们使用了非参数 Mann-Whitney U 检验 [31] 并在 95% 的置信水平（a = 0.05）下检验了我们的假设。在表 4 的第一部分，我们报告了单个 Mann-Whitney U 检验的 p - 值。可以看出，所有指标的 p 值都低于 alpha 水平。因此，在所有情况下，原假设都被拒绝。这表明在高 TD 和非高 TD 模块的指标值之间观察到统计上的显着差异，这表明所有这些指标都可以区分并可能用作高 TD 软件模块的预测因子。

为了补充 Mann-Whitney U 测试结果，表 4 还显示了数据集的高 TD 模块和非高 TD 模块的计算指标的中值。我们选择呈现中位数而不是平均值，因为不能假设指标的正态分布。可以看出，每个指标的中值往往不同。在所有情况下，这些指标似乎在高 TD 模块中获得了更高的价值，唯一的例外是贡献者的经验和评论行密度指标。

通过检查所研究指标的判别力，我们观察到它们的值表明高 TD 和非高 TD 模块之间存在统计学上的显着差异。为了就所选指标与模块的 TD 类别（高 TD/非高 TD）之间的关系得出更安全的结论，我们应用了单变量逻辑回归分析。单变量逻辑回归侧重于确定一个自变量（即每个指标）和因变量（即高 TD 类）之间的关系，并已广泛用于软件工程研究，以分别检查每个指标的影响 [32] , [33]。因此，我们使用这种方法来帮助我们识别高 TD 类和所选指标之间的潜在关系是否具有统计显着性以及程度如何。

表 4 总结了应用于我们数据集的每个指标的单变量逻辑回归分析的结果。列“Pseudo R 2”给出拟合优度指数伪 R 平方（McFadden 的 R 2 指数 [34]），它衡量模型似然度相对于空模型的改进。 “p - 值”和“SE”列分别显示自变量的统计显着性和标准误差。我们将显着性水平设置为 a = 0.05。 p - 值低于 0.05 的指标被认为对高 TD 类具有统计学意义。相反，p - 值大于 0.05 的指标可以从进一步分析中删除，因为它们不被认为具有统计显着性。在我们的案例中，所有 18 个指标都与高 TD 的概率显着相关（p - value ≤ 0.05）。

在表 4 的最后一列中，我们展示了每个指标的优势比 (OR)。简而言之，OR 是事件发生的概率与事件未发生的概率之比。在数学上，它可以通过采用估计系数的指数来计算，如通过应用逻辑回归得出的。考虑系数的指数的原因是，由于模型是Logit，我们不能通过检查初始系数值直接得出有用的结论（效果将是指数的）。因此，转换为 OR 在解释上更直观，如下所示：OR = 1 表示相同的赔率，OR < 1 表示赔率较小，OR > 1 表示赔率更大。例如，通过检查表 4 中的“OR”列，我们观察到指标贡献者计数的 OR 为 1.31，这表明贡献者数量增加一个单位（即额外的贡献者），我们预计标记为高 TD 的模块将增加 1.31 倍（即增加 31%）。另一方面，度量评论行密度的 OR 为 0.92，这表明对于包含评论的行的百分比增加一个单位，我们预计模块的几率会减少约 0.08 倍（即减少 8%）被标记为高TD。

为了结束探索性分析，Mann-Whitney U 检验显示所有指标都可以区分并可能用作高 TD 软件模块的预测因子。此外，单变量逻辑回归分析表明，所有指标都被发现与高 TD 的概率显着相关（p - 值 ≤ 0.05）。因此，在第 3.3 节中描述的模型构建过程中，表 3 中提供的整套指标将被视为输入。毕竟，众所周知，本研究中使用的一些 ML 模型可以消除他们认为在基于嵌入式特征选择方法的迭代过程中不重要的变量。

3.3 Model Building

本节提供有关模型构建过程的详细信息，该过程涉及 (i) 模型选择、(ii) 模型配置和 (iii) 性能评估等特定步骤。一般而言，我们的实验研究设计涉及一组候选分类学习算法，其中每个候选 AK 的目标是学习从输入变量（或预测变量） xi 到输出变量（或响应） yi ，其中 yi ∈ {0,1} 给定一组 n 输入输出观察，形式为。在我们的例子中，输出变量是将 TD 表征为非高 TD（用 0 表示）和高 TD（用 1 表示）以及通过第 3.1 节中描述的过程导出的输出变量。

3.3.1 Model Selection

考虑到有大量可用于分类目的的预测候选者，我们决定探索一组特定的完善的统计和 ML 算法，这些算法已广泛应用于其他类似的代码异味或错误预测实验研究[17]，[20]。更具体地说，我们使用了表 5 中总结的七个不同的分类器：两个是简单的统计/概率模型（逻辑回归 (LR)、朴素贝叶斯 (NB)），五个是更复杂的单一分类器（决策树 (DT) ，K-最近邻（KNN），支持向量机（SVM））或集成（随机森林（RF）和极限梯度提升（XGBoost））ML模型。

尽管候选分类器已被证明在许多应用领域中是有效的，但它们的性能受到类不平衡问题的显着影响[35]。这个具有挑战性的问题发生在分类任务中，当响应变量的类分布高度不平衡时，这实际上意味着一个类（少数类）与另一类（多数类）相比代表性不足。在这项研究中，由于问题的性质，响应变量存在内在的不平衡 [35]（比率 ~ 1:15），因此呈现高度倾斜的类别分布。这个事实给学习过程带来了问题，导致分类器的泛化能力很差，因为这些算法中的大多数都假设类分布是平衡的。此外，这些学习器中的大多数旨在最大化拟合模型的整体准确性（或总错误率），这反过来导致分类器倾向于偏向于对多数类呈现出色预测性能的模型，但在同时，少数民族班的表现极差。

类不平衡问题通常通过采用两种广为人知的技术来解决，即过采样和欠采样 [36]。过采样通过复制少数类数据来实现类之间所需的平衡，而欠采样通过从多数类中删除随机选择的数据来实现。在某些情况下，过采样和欠采样的组合效果更好[36]，即通过使用这两种技术的特定比率，直到实现精确度和召回率之间的理想权衡。

在当前的研究中，我们选择过采样而不是欠采样，因为我们希望避免从数据集中删除有价值的数据（从而避免模型性能可能下降）。此外，关于过采样率，我们选择增加少数类，直到其数据实例与多数类的数据实例相等（比率 1:1）。这一决定背后的原因是双重的。首先，1:1 的班级比例保证了少数班级的最佳表现，在本研究中，我们认为这比多数班级更重要。其次，在 ML 模型的评估过程中（在第 3.3.2 节中描述），我们注意到在尝试不同的过采样、欠采样或组合比率时，与分类器的性能相比，具有 1:1 的类比率会产生更好的性能指标两者的。

为了克服分类学习器在存在类不平衡输入变量的情况下为少数类和多数类提供准确预测的固有限制，我们使用了一种众所周知的合成采样方法，即合成少数过采样技术（SMOTE）[36 ]。 SMOTE 通过基于属于该类的最近邻生成新的合成实例来对少数类进行过采样。关于我们在何处以及如何将 SMOTE 集成到我们的实验设置中的更多详细信息，请参见第 3.3.2 节。

3.3.2 Model Configuration

为了评估每个分类器，我们采用了训练-验证测试方法。更具体地说，数据集分为两部分：80%（14,238 个样本）用于训练/验证，20%（3,559 个样本）用于测试。第一部分用于模型训练、调整和验证（使用交叉验证），而第二部分用作“期末考试”的保留集，即对完全看不见的数据的模型进行最终评估。数据拆分以分层方式进行，这意味着我们保留了两个部分中每个类别的样本百分比（即初始高 TD - 非高 TD 类别比率~ 1:15）。后者被认为是重要的一步，因为测试集保留初始类比是极其必要的，从而为最终模型评估创造现实条件。

从验证阶段开始，我们进行了 3 × 10 重复分层交叉验证 [37]。数据集被随机分成 10 份，其中 9 份参与训练，其余一份参与测试，每次测试折叠时旋转，直到每份都作为测试集。此外，最初对每个折叠进行分层以正确保留初始的高 TD - 非高 TD 类别比率。随后，过采样（使用 SMOTE）被集成到交叉验证过程中。尽管训练折叠经过过采样，但测试折叠始终保留初始类比以进行适当的模型验证。然后将整个 10 折交叉验证过程重复 3 次，以解决随机拆分中可能存在的抽样偏差。因此，在交叉验证期间生成的每个分类器的计算性能指标是在同一数据集上训练和评估的 30 个（3x10）模型的平均值。通过这种方式，我们减少了通过选择更广泛数据集的非代表性子集而引入偏差的可能性。

作为验证阶段的常见做法，我们采用超参数调整来确定每个分类器的最佳参数，从而提高其预测能力。为此，我们使用了网格搜索方法 [38]，该方法通常用于通过对估计器的指定参数值执行详尽搜索来找到最佳超参数。我们选择 F 2 度量作为估计器的目标函数来评估参数设置（有关选择 F 2 度量的更多细节在第 3.3.3 节中介绍）。使用分层的 3 × 10 折交叉验证进行超参数选择，以避免过度拟合，并确保微调分类器在评估其在测试集上的性能之前具有良好的泛化程度。在表 5 中，我们报告了在调整过程中调整的最佳超参数。

在验证阶段，我们还通过在零和一之间的范围内单独缩放每个特征来执行 MinMax 数据转换。这种选择背后的原因是，如果一个特征的方差比其他特征大几个数量级，它可能会在学习过程中占主导地位，从而使分类器无法正确地从其他特征中学习。通过应用 MinMax 转换，我们注意到大多数分类器的预测性能（和执行时间）都得到了改善，而其他分类器没有显着差异。同样，MinMax 变换被集成到分层的 3×10 折交叉验证过程中，在每次迭代期间，它仅适合训练折叠（以创建实际条件），然后用于变换训练和测试折叠。

最后，在通过上述验证阶段微调和评估我们的分类器之后，我们继续进行最后的测试阶段。更具体地说，我们使用训练/验证集重新训练了微调分类器，并将它们应用于测试集。再次使用过采样（使用 SMOTE）和 MinMax 变换，但仅在训练/验证集上使用，此时仅用于模型训练。在前一阶段（训练/验证）中，模型从未见过包含测试集的数据样本。我们的目标是创建一个假设但实际的情况，其中有一个新系统或一组系统可用，并且必须应用所提出的分类框架来预测新（一组）系统中高 TD 模块的存在（ s)。与在 30 (3x10) 次迭代中平均性能指标的交叉验证过程相比，在这种情况下，每个分类器的计算指标包含单个值，因为每个模型在整个测试集上执行一次。对于我们的实验，我们使用了 Python 语言，更具体地说是 scikitlearn 6 ML 库。

3.3.3 Performance Evaluation

在实践中，二元分类器的性能评估通常通过基于混淆矩阵构建的替代指标进行评估（表 6）。通常，在类不平衡的学习过程中，少数类和多数类被认为分别代表正（+）和负（-）输出[39]。

此外，事实上的评估指标（准确性和错误率）没有考虑错误分类属于少数类别的案例的成本和副作用。在我们的研究中也是如此，因为从实践者的角度来看，准确预测属于少数类的模块，即表现出高水平 TD 的模块非常重要。与 FP 相比，倾向于降低 FN 的理由源于这样一种信念，即与浪费精力检查错误报告的低 TD 模块相比，忽略高 TD 模块的影响可能被认为风险更大且对软件维护有害.
基于之前的考虑，我们使用了为处理类不平衡问题[35]而提出的适当评估指标。 F-measure 是一种广泛使用的结合精度和召回率的度量，定义如下：

其中 β 是用于调整精度相对于召回率的相对重要性的系数。上述每个指标都代表了预测性能的不同方面，为分类器的质量提供了直接的指导。精度和召回都集中在少数（正）类上，而前者被称为准确度的度量，而后者被称为完整性的度量[39]。将这两个指标结合起来是为了提供与分类器在正确预测少数情况下的有效性相关的整体评估指标，即在我们的实验设置中非常重要的类别。更重要的是，与 FP 错误分类的案例相比，F-measure 提供了一种直接的方式，通过设置 β = 2 导致 F-measure 的特殊情况，称为 F2 -measure，从而更加重视 FN。换句话说，我们认为开发团队忽略可能具有高 TD 的模块（即，遭受许多 FN 的存在，这可能导致有关维护的不适当决策）比通过许多模块风险更大被标记为有问题，而它们不是（即 FPs ）。因此，为了评估所选的二元分类模型集，我们选择 F2 度量作为我们的主要性能指标之一。

应该注意的是，与漏洞预测等其他领域不同，FN 的最小化被认为是最重要的，因此绝对强调召回，我们也重视 FP 的数量，因为它们的存在增加了研究所需的工作量报告的有问题的模块。因此，在我们的案例中，F 2 度量是理想的，因为它同时考虑了召回率和准确率，同时更加强调了前者。

如前所述，除了生成的模型能够准确检测尽可能多的高 TD 模块外，重要的是要考虑生成的 FP 的体积。大量 FP 与开发人员检查大量模块所需的人工工作量增加有关，以便检测实际的高 TD 模块。因此，即使我们使用 F 2 -measure 作为标准来测试模型的性能，我们也会通过测量所需的检查工作来进一步研究它们的实用性。

遵循与其他研究 [33]、[40]、[41] 类似的方法，我们使用要检查的模块数量作为检查工作的估计量。我们将模块检查 (MI) 比率定义为预测为高 TD 的模块（软件类）与模块总数的比率：

该性能指标本质上描述了开发人员必须检查的模块百分比，以便找到模型识别的 TP。例如，让我们考虑一个召回率等于 80% 的模型。在实践中，这意味着该模型能够正确识别 80% 的高 TD 模块。让我们也考虑一下这个模型的 MI 比率等于 10%。这意味着通过使用该模型，我们期望通过仅手动检查总模块的 10% 来找到 80% 的真正高 TD 模块 (TP)，即仅由模型预测为高 TD 的模块 ( TP + FP）。显然，使用这样的模型无疑比随机选择要检查的模块更具成本效益，因为在不使用该模型的情况下识别 80% 的高 TD 模块将需要我们检查 80% 的总模块。

总而言之，F2-measure 和 MI 性能指标被用作比较和选择最佳模型的基础，因为它们的组合提供了预测高 TD 模块的模型性能的完整画面。事实上，F 2 -measure 表示生成的模型在不忽略 FP 的情况下检测 TP 的效率（即，通过加权召回高于精度），而 MI 表示模型在预测 TP 方面的效率，基于必须有多少 FP由开发人员进行分类，直到检测到 TP。为了完整起见，在第 4 节中展示的实验结果中，我们报告了其他指标，如精度、召回和 Precision-Recall 曲线。

4 EXPERIMENTAL RESULTS

4.1 Quantitative Analysis

表 7 总结了通过第 3.3.2 节介绍的训练-验证-测试方法验证和测试的一组检查分类器的性能指标。更具体地说，“验证”列显示了通过重复的分层交叉验证过程（验证阶段）为每个分类器获得的结果。在这方面，结果提供了一个总体指标，该指标是通过对三个重复执行的 k = 10 倍的性能指标进行平均计算得出的。此外，还报告了标准偏差。另一方面，“测试”列显示了测试（保持）集上每个检查分类器的性能指标，即在训练/验证期间未使用的 20% 的数据集。在这两种情况下，就每个性能指标而言，最好的分类器都用粗体表示。如 3.3.3 节所述，我们将 F2-measure 和 MI 比率作为主要性能指标，因为它们涵盖了所生成模型的准确性和实用性。

表 7 的结果表明，有一个高级分类器的子集在 F2 测量方面呈现出小的差异。更具体地说，就验证阶段而言，LR 以 0.764 的值获得了最高的 F2 测量分数。然而，XGB、RF 和 SVM 分类器紧随其后，F2 测量得分在 0.758 和 0.761 之间。另一方面，KNN、NB 和 DT 似乎具有明显较低的 F2 测量分数。就测试（保持）集的结果而言，我们注意到分类器的性能不仅与验证阶段的结果相比得到了保留，而且还略高一些。更具体地说，RF 以 0.790 的 F2-measure 得分最高，紧随其后的是 XGB、LR 和 SVM，F2-measure 得分介于 0.781 和 0.788 之间。当然，整体性能评估完全基于从样本评估的统计测量，因此，它们包含显着的可变性，可能导致关于分类器子集相对于竞争分类器的优越性的错误决策。因此，识别优质模型的子集应基于统计假设检验 [42]。

对此，在通过验证阶段评估检查分类器的背景下，我们使用了多假设检验程序，即 ScottKnott (SK) 算法 [43]，该算法考虑了由同时比较引起的误差膨胀问题多个预测模型[44]。与其他传统假设程序相比，一个主要优势是该算法会产生具有相似性能的互斥分类器集群，因此解释和决策是一个简单的过程。最后，该算法完全基于既定的实验设计（DoE）统计概念，同时考虑了治疗和阻断因素。在我们的案例中，验证阶段由 30 个重复的性能测量（即 F2 测量）组成，在 3 次重复执行（阻塞效应）后从每个分类器（治疗效果）评估 k = 10 倍。简而言之，处理效果考虑了候选分类器集合之间的差异，而阻塞效应是一个应该考虑的附加因素，但我们并不直接感兴趣，它与将数据集拆分为不同的分类器有关分层交叉验证过程的每次执行的测试集。

SK 算法的结果表明 F2 测量具有统计学意义的治疗效果 (p < 0.001)，这意味着观察到的七个分类器之间的差异不可能是偶然发生的，并且确实存在一个高级分类器的子集F 2 测量值。在这方面，SK 算法产生了四个同质的分类器集群，可以在表 7 的最后一列中找到。分类器从最好的（用 A 表示）到最差的（用 D 表示）集群进行排序，而不存在统计上显着差异的分类器被分组到同一个簇中。最好的集群包含四个分类器（RF、XGB、LR 和 SVM），它们具有相似的预测性能。另一方面，DT 可以被认为是基于度量来识别模块是否是高 TD 的最差选择。

尽管我们将 F2-measure 视为主要性能指标之一，但属于最佳集群（集群 A）的分类器具有相似的预测能力。因此，值得检查替代措施所表达的性能的其他方面，以确定最佳选择。至于额外报告的性能指标，即精度和召回率，SVM 分类器在验证阶段显示出更高的召回率，值为 0.925，其次是 XGB 和 LR，值为 0.914。 SVM 在测试阶段也显示出更高的召回率，值为 0.954。然而，这三个分类器在验证和测试设置中的精度分数都低于 0.5，这可能会显着增加预测 FP 的数量。更具体地说，精度分数低于 0.5 将导致预测的 FP 的数量大于预测的 TP 的数量。另一方面，我们注意到虽然 RF（具有较高 F2-measure 测试分数的分类器）在验证阶段和测试阶段的召回分数分别为 0.822 和 0.858，但在这两种情况下，它的准确率分数都约为 0.6，这可以考虑到我们的训练配置更强调识别 FN 而不是 FP，因此被认为是令人满意的。

虽然我们认为开发团队忽略实际的高 TD 模块比检查许多被错误报告为高 TD 的模块风险更大，但声明显示高召回率和低精度的模型优于显示高精度和低召回率是大胆且有争议的。开发人员可能更喜欢检查大量可能有问题的模块，因为他们可以为重构活动提供大量资源。另一方面，另一个开发团队可能更喜欢一种模型，它可以减少工作量的浪费，即使代价是错过一些高 TD 模块的案例。毕竟，TD 管理是关于减少开发过程中浪费的精力 [2]。我们可以争辩说，RF 分类器在这两种情况之间取得了平衡，因为它提供了相当令人满意的召回分数，同时它保留了较低（但与其他模型相比明显更高）的精度分数。

为了补充上述分类性能指标的比较，我们还展示了每个分类器的 PrecisionRecall 曲线 [45]，对验证阶段遵循的 3 × 10 重复分层交叉验证过程的每个折叠的结果进行平均。 PrecisionRecall 曲线是显示不同概率截止值的精度（y 轴）和召回率（x 轴）之间权衡的图，因此提供了分类器在多个阈值上的性能的图形表示，而不是单个值（例如， F2-测量）。与绘制 FP 与 TP 率的 ROC 曲线相比，Precision-Recall 曲线是不平衡数据集的更好选择，因为没有考虑 TN 的数量 [45]。我们还为每个分类器提供曲线下面积 (AUC) 的值，总结他们在不同阈值下的技能。高 AUC 代表高召回率和高精度。从图 1 可以看出，RF 分类器的曲线更接近于最佳右上角，这实际上意味着与其他分类器相比，它可以通过牺牲更少的精度来获得相似的召回分数。此外，RF 的 AUC 最高，为 0.77，其次是 LR（AUC = 0.75）和 XGB（AUC = 0.74）。水平虚线描绘了一个“无技能”分类器，即预测所有实例都属于正类的分类器。它的 y - 值为 0.067，等于数据集中正例的比率。

关于第二个主要性能指标，即 MI 比率，通过检查表 7 中的测试阶段指标，我们可以看到 RF 具有最佳（即最低）得分，值为 0.092。考虑到 RF 在所检查的分类器中获得了迄今为止最好的精度分数，这可以看作是一个合乎逻辑的结果。高召回率和低准确率之间可能的权衡也对成本效益有影响。例如，让我们考虑一个来自我们数据集的项目。 JClouds 应用程序有大约 5,000 个模块，其中 126 个被标记为高 TD。 SVM 分类器以 14% 的 MI 比率提供最高的召回分数 (0.954)。这意味着开发团队必须检查 5,000 × 14% = 700 个潜在的高 TD 模块，以识别 95% 的真正高 TD 案例，即 120 个模块（并遗漏 6 个高 TD 模块）。另一方面，RF 分类器的召回分数为 0.858，MI 比率为 9%。这意味着开发团队必须检查 5,000×9% = 450 个潜在的高 TD 模块，以识别 86% 的真正高 TD 案例，即 108 个模块（并错过 18 个高 TD 模块）。同样，如果采用 SVM 而不是 RF 模型需要检查的额外 250 个模块是否值得由 SVM 模型识别的额外 12 个高 TD 模块是公司特定的决定。但是，我们认为追求中等精度和高召回率可能比以非常低的精度为代价追求最高召回率更具成本效益。

Fig. 1. Cross-validated Precision-Recall Curves

4.2 Sensitivity Analysis

为了调查每个项目所检查分类器的预测能力的潜在变化和排名不稳定性，我们决定进行敏感性分析。关于实验设置，我们执行了 21 次 3 × 10 重复分层交叉验证过程，在 21 次迭代中的每一次使用单个项目作为训练和测试每个检查分类器的数据集。为了评估分类器的性能，我们再次考虑了 F2 度量。我们必须澄清，我们无法对四个项目（即 gson、javacv、vassonic 和 xxl-job）进行上述分析，因为模块数量有限（min=64，max=112）使得无法执行交叉验证过程。敏感性分析的结果总结在表 8 中。

表格的每一行都展示了对每个数据集进行的分析得出的结果，并附有 SK 算法关于基于 F2 度量的统计假设检验程序的结果。属于最佳集群的分类器用粗体表示，而最后一行提供了分类器性能的概述，即分类器被分类到一组优越模型（用字母 A 表示）中的实验百分比。第一个有趣的发现涉及基于我们之前在合并数据集上进行的交叉验证实验（参见第 4.1 节）的分类器的排名稳定性，这也在表 8 的第一行中进行了描述。更具体地说，XGB 具有始终如一的出色预测能力，因为这个分类器在 23 次实验中的 22 次（95.45%）中被归为最佳聚类。此外，与在合并项目集上评估的相应指标相比，XGB 在 13 个数据集上表现出更好的 F2 测量分数。 RF 和 SVM 也可以被认为是一个很好的替代选择，在大多数数据集中都有值得注意的表现。另一方面，有强烈迹象表明分类器始终呈现中等（KNN 和 NB）和较差（DT）的预测能力，这一发现与从所有项目的实验中获得的结果一致。

根据第 4.1 节和第 4.2 节的结果，更复杂的算法（如 RF、XGB 和 SVM）比其他更简单的算法（如 DT 或 NB）表现更好也就不足为奇了。这是一个笼统的说法，经常在各种分类，甚至回归任务中遇到。在我们的案例中，与其他检查的分类器相比，XGB、RF 和 SVM 表现出显着更高的性能的发现可能归因于当数据中存在非线性基础关系时这三种算法脱颖而出的事实，即也适用于我们的案例。此外，XGB 和 RF，即两种基于集成决策树的算法，被评为性能最佳的前 2 位算法，这一事实也与类似研究的结果一致（如第 2 节所述），其中基于树的集成算法（例如，RF）已被证明是相关经验 SE 研究中最流行和最有效的分类器之一。

4.3 Illustrative Examples of Identifying High-TD Classes

为了补充定量分析，我们还包括指示性定性结果。更具体地说，在下文中，我们从数据集中展示了三个不同的模块案例，其中不仅三个 TD 工具之间就它们的 TD 级别（即高/不高 TD）达成一致，而且后者也是正确的由我们的高级分类器的子集预测。

作为第一个示例，Mina 项目的模块 SslSocketFactory.java，属于 TD Benchmarker 的 Max-Ruler 配置文件（即，基于所有三个工具的结果的高 TD）的模块，被识别为高-TD 也由我们的上级分类器的子集组成。为了理解为什么这个模块首先被标记为高 TD，我们需要仔细看看三个 TD 评估工具（即 SonarQube、CAST 和 Squore）产生的分析结果。关于 SonarQube，该工具发现了四个代码异味问题（其中一个是严重的，一个是严重的）、注释行密度低（3.9%）和相对较高的圈复杂度（15），尽管该模块的尺寸很小（即 73 ncloc）。关于 CAST，该工具已识别出各种问题，例如高耦合和低内聚（即“高度缺乏内聚的类”、“对象间高耦合的类”），将其标记为高严重性问题。此外，与 SonarQube 类似，CAST 也将缺少注释（即“注释/代码比率非常低的方法”）指出为中等严重性问题。最后，关于 Squore，该工具确定了 8 个中等严重性的可维护性问题（例如，“不允许多个函数退出”），并且与其他工具类似，它指出了缺少注释（即，“工件未记录或正确评论”）。

在另一个示例中，Nacos 项目的模块 IoUtils.java 也属于 Max-Ruler 配置文件，被我们的高级分类器子集正确识别为高 TD。 SonarQube 已识别出 17 个代码异味问题和 3 个错误（其中 2 个严重错误和 8 个主要错误）、非常低的注释行密度 (0.7%) 和高圈复杂度 (36)，尽管该模块的尺寸很小（即 152 ncloc ）。 SonarQube 还确定了 30% 的重复线密度。关于 CAST，该工具已经识别出各种问题，例如高耦合和低内聚（即“高缺乏内聚的类”、“具有高对象之间耦合的类”），以及一些错误发生（即“关闭最外层流尽快”、“避免在循环终止表达式中调用方法”等），所有这些都标记为高严重性问题。与 SonarQube 类似，CAST 也指出了高圈复杂度（即“Artifacts with High Cyclomatic Complexity”）、缺乏注释（即“Methods with a very low comment/code ratio”），以及代码重复问题（即“复制粘贴的工件太多”）。最后，Squore 还发现了各种可维护性问题（例如，“考虑类重构”、“不允许多个函数退出”等），其中三个被标记为主要问题。与之前的工具类似，Squore 也突出了高圈复杂度（即“圈复杂度不得太高”）、低评论率（即“工件未记录或未正确评论”），最后是代码重复（即“克隆函数：不应有重复函数”）。

在第三个例子中，Fop 项目的模块 CharMirror.java 是正确的被我们的高级分类器的子集分类为非高 TD。关于 SonarQube，该工具没有发现任何错误、代码异味或其他问题，而与其大尺寸 (732 ncloc) 相比，它的圈复杂度非常低 (8)。关于 CAST，该工具仅识别出一个高严重性问题（即“不兼容突变期间的数值数据损坏”），而没有高耦合和低内聚问题。最后，Squore 只发现了三个轻微的问题（例如，“不允许多个函数退出”），没有进一步的问题。

5 IMPLICATIONS TO RESEARCHERS AND PRACTITIONERS

在这项研究中，我们尝试以高 TD 模块基准的形式利用领先的 TD 评估工具应用所获得的知识。考虑到 18 个指标作为特征，该基准允许构建可以准确地将模块分类为高 TD 的 ML 模型。最佳分类器相对较高的性能使从业者能够在他们自己的系统中识别候选 TD 项目，并高度确定这些项目确实存在问题。相同的模型为研究人员提供了进一步实验和分析高 TD 模块的机会，而无需求助于大量商业和开源工具来建立基本事实。可以在线获得一个原型工具，该工具能够将软件模块分类为任意 Java 项目的高/低 TD。

人们普遍认为 ML 模型作为黑匣子运行，限制了它们的可解释性。为了解决这个限制，我们试图揭示所选特征的预测能力。虽然发现所有 18 个检查指标都与高 TD 的概率显着相关，但所提供的统计结果可以推动进一步研究与 TD 存在更密切相关的因素，从而制定其预防指南。

6 THREATS TO VALIDITY

对外部有效性的威胁涉及结果的普遍性。此类威胁在研究中固有地存在，因为在 25 个项目的样本集上检查了 ML 模型将软件模块分类为高 TD/非高 TD 的适用性。虽然另一组项目总是有可能表现出不同的现象，但所选项目在应用程序领域、规模等方面非常多样化的事实部分缓解了这些威胁。另一个威胁源于所检查的数据集由 Java 项目组成，从而限制了将结论推广到不同编程语言的软件系统的能力。然而，本文中描述的构建分类模型的过程主要建立在用于计算软件相关指标的工具的输出之上，这些指标可以作为分类 TD 模块（高 TD/非高 TD）的预测因子。这意味着只要有支持提取此类指标的工具，所提出的模型就可以很容易地适应以不同的 OO 编程语言编码的项目模块的分类。最后，由于数据集不包括行业应用，我们不能对闭源应用做任何推测。商业系统以及其他 OO 编程语言可以成为未来工作的主题。

对内部有效性的威胁涉及可能影响正在调查的变量的意外关系或外部因素。关于自变量的选择，可以合理地假设许多其他影响 TD 的软件相关指标可能没有被考虑在内。然而，我们基于文献中广泛使用的指标构建了 TD 预测器集这一事实限制了这种威胁。关于我们决定不执行特征选择并将整个指标集（如表 3 所示）作为分类模型的输入，我们通过使用假设检验和单变量逻辑回归分析来研究它们的判别和预测能力来避免选择偏差。随后，发现所有指标都对预测高 TD 软件模块具有重要意义。最后，如第 3.3 节所述，我们采用过采样来提高分类器在预测少数类时的有效性。尽管如此，我们承认平衡数据集可能会导致分布与现实生活中的预期大相径庭，因此可能导致实践中的模型不太准确。调查是否可以创建基于反映真实分布的数据训练的同样准确的模型将是未来工作的主题。

构建有效性的威胁涉及理论与观察之间的关系。在这项工作中，构建有效性威胁主要源于为收集软件相关指标（即自变量）而执行的测量中可能存在的不准确，但也源于为构建 TD Benchmarker [5] 而执行的测量中的不准确（即，因变量）。为了降低与数据收集过程相关的风险，我们决定使用五种众所周知的工具，这些工具已广泛用于类似的软件工程研究，以提取与软件相关的指标 [14]、[15]、[23]、[ 46]，[47]。至于因变量，即在 Amanatidis 等人的背景下创建的 TD Benchmarker。 [5]，构造有效性威胁主要是由于三种采用的工具（即 SonarQube、CAST 和 Squore）执行的静态分析测量可能不准确。然而，这三个平台都是主要的 TD 工具，被软件行业和研究人员广泛采用 [4]。关于我们决定仅将所有三个 TD 工具都识别为高 TD 的模块（即属于 Max-Ruler 配置文件）考虑为高 TD，我们认为，虽然被多个工具识别为高 TD 的模块需要更多开发团队的注意，可以在任何提供的数据集上训练 ML 模型。如果开发团队希望标记为高 TD 模块，即使是仅由三个工具中的一小部分（例如，三分之二）标识的模块，可以选择不同的原型（例如，合作伙伴资料 [5] ) 用于提取训练数据集。在工业环境中，训练数据集也可以来自对问题类的实际标记，以反映开发人员对高 TD 的看法。至于实验的分类模型，我们利用了 scikit-learn 库提供的 ML 算法实现，该库被广泛认为是一种可靠的工具。

可靠性有效性威胁涉及复制这项研究的可能性。为了便于复制，我们提供了一个实验包，其中包含构建的数据集，以及用于数据收集、数据准备和分类模型构建的脚本。这个材料可以在网上找到 8。此外，25 个被检查项目的源代码可在 GitHub 上公开获取，以获得相同的数据。最后，作为实际验证我们方法的一种手段，我们在支持材料中提供了一个原型工具，该工具能够将软件模块分类为任何 Java 项目的高 TD/非高 TD。我们相信，该工具将通过在学术或工业环境中的使用实现进一步的功能实验，并将为更多数据驱动的 TD 管理工具铺平道路。

7 CONCLUSION AND FUTURE WORK

在这项研究中，我们调查了著名的机器学习算法将软件模块分类为高 TD 与否的能力。作为基本事实，我们考虑了从三个领先的 TD 工具在 25 个 Java 开源项目中的应用中提取的高 TD 类基准。作为模型特征，我们考虑了 18 个指标，涵盖了广泛的软件特征，从代码指标到重构和存储库活动。

研究结果表明，高级分类器的一个子集可以有效地识别高 TD 软件类，在测试集上实现了大约 0.79 的 F2 测量分数。发现相关的模块检查率约为 0.10，而召回率接近 0.86，这意味着开发团队必须检查十分之一的系统类别，以识别 86% 的所有真正的高 TD 类别。通过应用 Scott-Knott 算法，发现随机森林、逻辑回归、支持向量机和 XGBoost 具有相似的预测性能。这样的模型包含多个 TD 识别工具的汇总知识，从而增加了所识别的类别确实遭受高 TD 的确定性。进一步的研究可以集中在问题类别的共同特征上，旨在建立有效的 TD 预防指南。

REFERENCES

[1] P. Avgeriou, P. Kruchten, I. Ozkaya, and C. Seaman, “Managing technical debt in software engineering (dagstuhl seminar 16162),” in Dagstuhl Reports, vol. 6. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2016.

[2] T. Besker, A. Martini, and J. Bosch, “Software developer productiv- ity loss due to technical debt—A replication and extension study examining developers’ development work,” Journal of Systems and Software, vol. 156, pp. 41–61, 2019.

[3] G. Suryanarayana, G. Samarthyam, and T. Sharma, Refactoring for software design smells: managing technical debt. Morgan Kaufmann, 2014.

[4] P. Avgeriou, D. Taibi, A. Ampatzoglou, F. Arcelli Fontana, T. Besker, A. Chatzigeorgiou, V. Lenarduzzi, A. Martini, A. Moschou, I. Pigazzini, N. Saarimäki, D. Sas, S. Toledo, and A. Tsintzira, “An Overview and Comparison of Technical Debt Measurement Tools,” IEEE Software, accepted for publication, 2021.

[5] T. Amanatidis, N. Mittas, A. Moschou, A. Chatzigeorgiou, A. Am- patzoglou, and L. Angelis, “Evaluating the agreement among tech- nical debt measurement tools: building an empirical benchmark of technical debt liabilities,” Empirical Software Engineering, vol. 25, no. 5, pp. 4161–4204, 2020.

[6] G. A. Campbell and P. P. Papapetrou, SonarQube in action, 1st ed. Manning Publications Co., 2013.

[7] B. Curtis, J. Sappidi, and A. Szynkarski, “Estimating the principal of an application’s technical debt,” IEEE software, vol. 29, no. 6, pp. 34–42, 2012.

[8] B. Baldassari, “SQuORE: a new approach to software project assessment.” in International Conference on Software & Systems En- gineering and their Applications, vol. 6, 2013.

[9] M. O. Elish and K. O. Elish, “Application of TreeNet in Predicting Object-Oriented Software Maintainability: A Comparative Study,” in 2009 13th European Conference on Software Maintenance and Reengineering (CSMR), 2009, pp. 69–78.

[10] A. Chug and R. Malhotra, “Benchmarking framework for main- tainability prediction of open source software using object ori- ented metrics,” International Journal of Innovative Computing, Infor- mation and Control, vol. 12, no. 2, pp. 615–634, 2016.

[11] R. Malhotra and K. Lata, “On the Application of Cross-Project Validation for Predicting Maintainability of Open Source Software using Machine Learning Techniques,” in 2018 7th International Con- ference on Reliability, Infocom Technologies and Optimization (ICRITO). IEEE, 2018, pp. 175–181.

[12] N. S. R. Alves, T. S. Mendes, M. G. d. Mendonc ¸a, R. O. Sp´ ınola, F. Shull, and C. Seaman, “Identification and management of tech- nical debt: A systematic mapping study,” Information and Software Technology, vol. 70, pp. 100 – 121, 2016.

[13] F. A. Fontana, M. V. Mäntylä, M. Zanoni, and A. Marino, “Com- paring and experimenting machine learning techniques for code smell detection,” Empirical Software Engineering, vol. 21, no. 3, pp. 1143–1191, 2016.

[14] D. Cruz, A. Santana, and E. Figueiredo, “Detecting Bad Smells with Machine Learning Algorithms: An Empirical Study,” in Pro- ceedings of the 3rd International Conference on Technical Debt (TechDebt ’20). ACM, 2020, pp. 31–40.

[15] F. Pecorelli, F. Palomba, F. Khomh, and A. De Lucia, “Developer- Driven Code Smell Prioritization,” in Proceedings of the 17th In- ternational Conference on Mining Software Repositories (MSR ’20). ACM, 2020, pp. 220–231.

[16] S. Lujan, F. Pecorelli, F. Palomba, A. De Lucia, and V. Lenar- duzzi, “A Preliminary Study on the Adequacy of Static Analysis Warnings with Respect to Code Smell Prediction,” in Proceed- ings of the 4th ACM SIGSOFT International Workshop on Machine- Learning Techniques for Software-Quality Evaluation (MaLTeSQuE 2020). ACM, 2020, pp. 1–6.

[17] M. I. Azeem, F. Palomba, L. Shi, and Q. Wang, “Machine learning techniques for code smell detection: A systematic literature review and meta-analysis,” Information and Software Technology, vol. 108, pp. 115–138, 2019.

[18] R. Abbas, F. A. Albalooshi, and M. Hammad, “Software Change Proneness Prediction Using Machine Learning,” in 2020 Inter- national Conference on Innovation and Intelligence for Informatics, Computing and Technologies (3ICT), 2020, pp. 1–7.

[19] N. Pritam, M. Khari, R. Kumar, S. Jha, I. Priyadarshini, M. Abdel- Basset, H. V. Long, and others, “Assessment of Code Smell for Predicting Class Change Proneness Using Machine Learning,” IEEE Access, vol. 7, pp. 37414–37425, 2019.

[20] V. Lenarduzzi, F. Lomio, H. Huttunen, and D. Taibi, “Are sonar- qube rules inducing bugs?” in 2020 IEEE 27th International Con- ference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2020, pp. 501–511.

[21] T. Menzies, J. Greenwald, and A. Frank, “Data mining static code attributes to learn defect predictors,” IEEE Transactions on Software Engineering, vol. 33, no. 1, pp. 2–13, 2007.

[22] M. D’Ambros, M. Lanza, and R. Robbes, “Evaluating defect pre- diction approaches: a benchmark and an extensive comparison,” Empirical Software Engineering, vol. 17, no. 4, pp. 531–577, 2012.

[23] M. Aniche, E. Maziero, R. Durelli, and V. Durelli, “The Effective- ness of Supervised Machine Learning Algorithms in Predicting Software Refactoring,” IEEE Transactions on Software Engineering, accepted for publication, 2020.

[24] D. Spadini, M. Aniche, and A. Bacchelli, “PyDriller: Python Frame- work for Mining Software Repositories,” in The 26th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), 2018.

[25] N. Tsantalis, A. Ketkar, and D. Dig, “RefactoringMiner 2.0,” IEEE Transactions on Software Engineering, 2020.

[26] M. Aniche, Java code metrics calculator (CK), 2015.

[27] G. Digkas, A. N. Chatzigeorgiou, A. Ampatzoglou, and P. C. Avgeriou, “Can Clean New Code reduce Technical Debt Density,” IEEE Transactions on Software Engineering, accepted for publication, 2020.

[28] M. R. Smith and T. Martinez, “Improving classification accuracy by identifying and removing instances that should be misclassi- fied,” in International Joint Conference on Neural Networks (IJCNN 2011), 2011, pp. 2690–2697.

[29] M. Kuhn and K. Johnson, Applied predictive modeling, 1st ed. Springer, 2013.

[30] M. M. Breunig, H.-P. Kriegel, R. T. Ng, and J. Sander, “LOF: Identifying Density-Based Local Outliers,” SIGMOD Rec., vol. 29, no. 2, pp. 93–104, 2000.

[31] H. B. Mann and D. R. Whitney, “On a test of whether one of two random variables is stochastically larger than the other,” The annals of mathematical statistics, pp. 50–60, 1947.

[32] Y. Zhou and B. Xu, “Predicting the maintainability of open source software using design metrics,” Wuhan University Journal of Natural Sciences, vol. 13, no. 1, pp. 14–20, 2008.

[33] E. Arisholm and L. C. Briand, “Predicting fault-prone components in a java legacy system,” in Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering and mea- surement (ESEM). ACM, 2006, pp. 8–17.

[34] D. McFadden and others, “Conditional logit analysis of qualita- tive choice behavior,” Institute of Urban and Regional Development, University of California, 1973.

[35] H. He and E. A. Garcia, “Learning from Imbalanced Data,” IEEE Transactions on Knowledge and Data Engineering, vol. 21, no. 9, pp. 1263–1284, 2009.

[36] N. V. Chawla, K. W. Bowyer, L. O. Hall, and W. P. Kegelmeyer, “SMOTE: synthetic minority over-sampling technique,” Journal of artificial intelligence research, vol. 16, pp. 321–357, 2002.

[37] H. He and Y. Ma, Imbalanced learning: foundations, algorithms, and applications. John Wiley & Sons, 2013.

[38] M. Feurer, A. Klein, K. Eggensperger, J. Springenberg, M. Blum, and F. Hutter, “Efficient and robust automated machine learning,” in Proceedings of the 28th International Conference on Neural Informa- tion Processing Systems (NIPS), vol. 2, 2015, pp. 2962–2970.

[39] P. Branco, L. Torgo, and R. P. Ribeiro, “A Survey of Predictive Modeling on Imbalanced Domains,” ACM Comput. Surv., vol. 49, no. 2, 2016.

[40] Y. Shin, A. Meneely, L. Williams, and J. A. Osborne, “Evaluating complexity, code churn, and developer activity metrics as indi- cators of software vulnerabilities,” IEEE Transactions on Software Engineering, vol. 37, no. 6, pp. 772–787, 2011.

[41] J. Walden, J. Stuckman, and R. Scandariato, “Predicting vulner- able components: Software metrics vs text mining,” International Symposium on Software Reliability Engineering (ISSRE), pp. 23–33, 2014.

[42] J. Demˇ sar, “Statistical Comparisons of Classifiers over Multiple Data Sets,” J. Mach. Learn. Res., vol. 7, pp. 1–30, 2006.

[43] A. J. Scott and M. Knott, “A Cluster Analysis Method for Grouping Means in the Analysis of Variance,” Biometrics, vol. 30, no. 3, pp. 507–512, 1974.

[44] N. Mittas and L. Angelis, “Ranking and Clustering Software Cost Estimation Models through a Multiple Comparisons Algorithm,” IEEE Transactions on Software Engineering, vol. 39, no. 4, pp. 537– 551, 2013.

[45] J. Davis and M. Goadrich, “The Relationship between Precision- Recall and ROC Curves,” in Proceedings of the 23rd International Conference on Machine Learning (ICML ’06). ACM, 2006, pp. 233– 240.

[46] Z. Codabux and C. Dutchyn, “Profiling Developers Through the Lens of Technical Debt,” in Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Mea- surement (ESEM ’20). ACM, 2020.

[47] V. Lenarduzzi, N. Saarimäki, and D. Taibi, “The technical debt dataset,” in Proceedings of the Fifteenth International Conference on Predictive Models and Data Analytics in Software Engineering, 2019, pp. 2–11.

声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：【wpsshop博客】