摘要

自我承认的技术债务（SATD）是技术债务的一个子类型。引入它是为了代表开发人员在软件开发过程中故意引入的此类技术债务。 SATD 的引入虽然能够获得短期收益，但往往需要以更高的成本在以后偿还，例如，将错误引入软件或增加软件的复杂性。为了解决这些问题，我们的社区提出了各种基于机器学习的方法来检测 SATD。然而，这些方法要么不是通用的，通常需要手动特征工程工作，要么没有提供有希望的方法来解释预测的结果。为此，我们向社区提出了一种新颖的方法，即 HATD（基于混合注意力的自我承认技术债务检测方法），以使用基于注意力的神经网络检测和解释 SATD。通过对 20 个项目中 445,365 条评论的广泛实验，我们表明 HATD 在项目内和跨项目设置的 Iab 和野外数据集上都能有效地检测 SATD。在检测和解释 SATD 方面，HATD 的表现也优于最先进的方法。

1 引言

技术债务是一个隐喻，由 Cunningham [6] 提出，用于表示开发人员在开发过程中采取捷径实现快速交付的次优解决方案。技术债务的一些典型例子包括在代码中引入硬编码值，在忽略失败的单元测试的情况下进行代码更改，从其他模块复制粘贴代码等。这些技术债务通常是由开发人员无意中引入软件系统的，或者故意但没有充分记录。随着时间的推移，那些未记录在案的技术债务，如果不及时解决，可能会从开发人员的脑海中淡出，变成相当于无意引入的技术债务 [2, 45]。为了缓解这个问题，开发人员可能决定（通过评论）记录他们有意引入的技术债务。记录在案的债务通常被称为自我承认的技术债务（简称SATD）。

无论有意还是无意，为引入技术债务而做出的妥协都可能对长期软件的维护产生负面影响 [18, 21, 23, 27, 35, 53]。事实上，正如 Megan Horn 1 所说，技术债务可能会导致软件系统出现意外行为，而众所周知，这些令人惊讶的行为可能难以测试和修复。通常，解决一个问题可能会引入多个新问题，从而导致解决技术债务的高成本。正如软件分析和测量工具提供商 CAST Software 2 最近的一项研究所揭示的那样，在将应用程序部署到生产环境后必须解决的技术债务数量平均超过每个业务应用程序的一百万。

尽管技术债务会给软件的维护带来负面影响，但技术债务仍然普遍存在，并且在软件系统中似乎是不可避免的[3,12,47,54]。因此，迫切需要发明自动化方法来检测技术债务并尽早修复它们。然而，一次处理所有类型的技术债务是一项具有挑战性的工作 [25, 38]。作为实现这一目标的第一步，许多最先进的工作首先关注SATD的检测[10,14,17,58]。与其他技术债务不同，SATD 通常在软件代码中作为注释突出显示 [30,41,59]。表 1 列举了一些流行的开源项目中确定的 SATD 示例。例如，JMeter 项目中的注释“稍后可能会被替换”表示当前代码是临时解决方案，未来需要替换。

尽管明确强调，如表 1 所示，SATD 仍然主要出现在开源软件项目中。因此，我们的社区花费了各种努力来实验性地表征 SATD。例如，Potdar 等人。 [38]尝试在java项目的代码注释中手动探索SATD，并最终总结出62种可用于识别SATD的模式。黄等人 [16]提出了一种文本挖掘方法来识别SATD，并且与基于模式的方法相比取得了实质性的改进。 Yan 等人 [56] 提出了一种利用 25 个软件更改特征检测 SATD 的更改级别方法。

不幸的是，现有的最先进的方法要么涉及繁重的手动预处理（例如识别与 SATD 相关的模式或提取特征以实现基于 ML 的分类器），要么缺乏可靠的解释来阐明为什么将 SATD 标记为这样的[4,43,50,51,60]。为了填补这一空白，我们向社区提出了一种新颖的基于深度学习的方法来检测和解释开源软件项目中自我承认的技术债务。我们设计并实现了一个名为 HATD 的原型工具。首先，它利用位置编码器和双向长短期记忆（Bi-LSTM）[64] 网络从代码注释中捕获 SATD 的顺序特征。然后，它利用各种注意机制来突出自动准备的特征的重要性，这些特征有助于检测 SATD。随后将利用最重要的特征来解释分类结果，例如，为什么评论被（不）标记为 SATD？通过对 20 个项目中 445,365 条评论的广泛实验，HAm 证明了其在项目内和跨项目 SATD 检测中优于最先进方法的卓越性能和可解释性。

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

• 我们提供了代码注释特征的概述，这些特征对于创建自动化工具来检测软件项目中的SATD 可能具有挑战性。

• 我们设计并实现了一个名为HATD 的原型工具，它利用基于混合注意力的方法结合了单头注意力和多头注意力机制，从代码注释中精确定位SATD。

• 我们通过在开源基准项目中与最先进的方法进行比较、在现实世界和流行的软件项目中检测SATD，并对分类结果提供解释，证明了HAm 的有效性。

2 动机和背景

为了帮助读者更好地理解我们的工作并激发开发用于精确定位 SATD 的自动化方法的必要性，我们首先在本节中介绍一个简单的实证调查，以检查 SATD 是否影响软件项目的可维护性。然后，我们列举了代码注释的一些特征，这些特征使得自动解释注释的语义变得具有挑战性（即查明自我承认的技术债务）。

2.1 SATD VS. Code Changes

直观地说，SATD 将触发更多的未来代码更改，即增加软件项目的可维护性 [39, 55]。为了量化 SATD 和代码更改之间的关系，我们进行了一项简单的实证研究（计算与已更改文件相关的提交次数，无论有无技术债务），以检查 SATD 是否会触发更多的未来代码更改。为此，我们选择了一个名为 Apache Ant 的流行开源项目来完成实验。选择这个项目的原因是在这个项目的开发过程中引入的SATDs是已知的。事实上，截至 2016 年 1 月 14 日，Apache Ant 项目总共引入了 131 个 SATD，约占总评论的 3.2%（参见 4,137）。

为了探索SATDs对项目维护的长期影响，我们在2014年1月1日设定了一个切入点，并重新计算了当时引入的SATDs。在131个SATD中，有111个已经被引入到项目中，还没有解决，涉及82个Java文件。换言之，此时，SATD 不涉及 1,116 个 Java 文件。从这个切入点开始，我们重新审视所有即将到来的提交以及与每个 Java 文件相关的更改时间。最终结果绘制在图 1 中，该图说明了对涉及 SATD 和不涉及 SATD 的 Java 文件所做更改的分布。很明显，与不涉及 SATD 的文件相比，涉及 SATD 的文件需要更多的更改。 Mann-Whitney-Wilcoxon (MWW) 检验进一步证实了这种差异，即差异在显着性水平为 0.001 时显着。这个简单的实证调查表明，SATD 确实会对软件项目的维护产生负面影响，因此非常需要发明有前途的方法来检测和解决它们 [13]。

2.2 Characteristics of Code Comments

开发人员经常提供代码注释来提醒自己记录不满意的设计决策，质疑其他开发人员的设计决策，并做出未来的改变。由于代码注释通常由具有不同写作风格的不同开发人员用自然语言编写，因此它们可能具有难以解释的特征 [31]。在本节中，我们总结了代码注释的一些特征，这些特征使得自动检测 SATD 具有挑战性：

(1)域语义。代码注释通常包含只有程序员才能理解的行话、方法名称和抽象概念。例如，JRuby 项目中的注释“FIXME：我使用 afor 块来实现 END 节点，因为我们需要一个捕获的 proc”中包含一个术语，即抽象概念 END 节点。
(2) 详细程度（评论长度）。代码注释中短语的长度可以变化很大，从“未使用”、“加载”之类的一个词，到“调用解决方法”、“应该可能出错”之类的短语，再到“这是一种糟糕的方式”之类的句子。这样做，但是 .. :'。代码注释中这种不同长度的文本特性使得检测 SATD 也具有挑战性。
(3)项目唯一性。正如 Potdar 等人的经验证实，SATD 对不同项目的评论会因开发者的不同而呈现出不同的风格。 [38]在他们的mauual模式总结工作中。此外，不同开发者之间的编码习惯和词汇量差距也加剧了这种现象。
(4)多义性。多义词在句子表达中很常见。它通常伴随着代码注释中的领域知识。例如，代码注释可能包含方法名称。区分方法名称和常用词具有挑战性，这通常需要上下文信息。
(5)缩写。为了便于记忆和写作效率，开发人员经常在代码注释中使用缩写。项目差异往往会加剧这种现象。例如，注释“DB 中没有默认值。如果可以为空，请使用 null。”在 SQuirrel 项目中，其中 DB 是 Database 的缩写。

这些在SATD评论中经常表现出来的特征使得传统的基于模式的基于文本挖掘的SATD检测方法难以实现高性能。因此，迫切需要从代码注释中深入挖掘隐含和语义特征，以满足有效检测SATD的不同挑战。

3 我们的方法

我们提出了一种基于混合注意力的自我承认技术债务检测方法，名为 HATD。 HATD 分析不同项目或应用程序域（挑战 1 和 3）的代码注释，旨在学习 SATD 的综合隐式特征。它可以灵活地提取和聚合 SATD 检测的可变长度文本特征（挑战 2）。为了克服多义词和缩写问题（挑战 4 和 5），我们使用 ELMo 获得跨上下文的动态词嵌入以进行 SATD 检测。

如图 2 所示，HATD 具有三个模块。词嵌入模块将评论中的词映射到向量。可以将不同的词嵌入技术结合到我们的方法中（默认情况下，实现了 ELMo 算法）。在特征学习模块中，我们使用位置编码器和 Bi-LSTM 来学习序列特征，然后我们利用不同的注意力机制进一步获得单词的潜在表示并区分不同单词的重要性。最后，将学习到的特征输入检测模块以预测 SATD。

3.1 Word Embedding

词嵌入是自然语言处理（NLP）中语言模型和表示学习技术的统称。从概念上讲，它是指将一个维数为所有单词数的高维向量嵌入到一个维数低得多的向量中。词嵌入模块的目标是在处理代码注释时克服上述挑战（参见第 2.2 节）。让我们考虑代码注释中的关键字 proc 示例“FIXME：我使用 afor 块来实现 END 节点，因为我们需要一个捕获的 proc”在 JRuby 项目中。这里的proc是process的缩写，可以看成OOV（out of words）。因为标注的代码注释是有限的，我们不能保证训练语料中存在任何测试词。根据形态学知识，FastText[5, 19]通过学习基于字符的子词嵌入表示，在一定程度上解决了OOV问题。静态词嵌入技术无法处理评论中常见的多义现象。 ELMo[37]等动态词表示技术可以通过根据上下文调整词向量在一定程度上解决这个问题。 ELMo（Embedding from Language Models）[37] 是一种新型的深度上下文化词表示语言模型，它对词的复杂特征（如句法和语义）和词在语言上下文中的变化（即多义性）进行建模。）。由于词的含义是上下文相关的，所以ELMo的原理是将句子实时输入到预先训练好的语言模型中，得到动态词向量，可以有效地处理多义词。考虑到 ELMo 的主要应用场景是提供动态词向量，作用于下游任务，我们的模型集成了 ELMo 来识别 SATD。现有词嵌入方案的详细比较可以在第 5.3 节中找到。

3.2 Feature Learning

特征学习模块由两个子模块组成，一个单头注意力编码器（SAE）和一个多头注意力编码器（MAE），采用不同的注意力机制和序列特征提取器。单头注意力编码器首先将评论的嵌入表示输入到 Bi-LSTM 网络中，然后我们可以使用注意力机制根据单词的重要性为不同的单词分配不同的权重，以解释检测结果。为了进一步编码当前单词，多头注意力编码器允许通过所谓的自注意力机制考虑其他单词信息对单词进行编码。通过结合 SAE 和 MAE 模块，我们希望利用基于 RNN 的模型 [64] 和基于 Transformer 的模型 [48] 的优势来提高 SATD 检测性能并通过注意力机制解释检测结果。图 3 显示了特征学习模块的内部结构。这两个内部子模块的细节将在后面给出（略）。

3.3 SATD Detection

最后，如图6所示，将S1和S2连接起来形成代码注释的抽象表示，然后输入到全连接层ffc进行SATD检测。预测结果由 sigmoid 函数计算。分类规则由以下等式定义：

如表 2 所示，SATD 和非SATD 评论在开源项目中的分布非常不平衡[20]。为了解决数据不平衡问题，我们引入加权交叉熵损失作为损失函数，而不是下采样或应用可能牺牲特征学习能力的特征选择。假设训练数据中有一条SATD评论和b条非SATD评论，那么损失函数定义为：

4 实验设置

在本节中，我们对SATD检测进行了综合实验，旨在回答以下研究问题：
• RQ1：HATD 在检测软件项目中自我承认的技术债务方面是否有效？
• RQ2：HATD 与识别自我承认的技术债务的最新方法相比如何？
• RQ3：与其他基线技术相比，集成到HATD 中的词嵌入技术的效果如何？
• RQ4：在现实世界的软件项目中，自我承认的技术债务在多大程度上存在？

4.1 Dataset Description

在我们的实验中，我们使用 [7] 提供的数据集。该数据集包含 ApacheAnt、ArgoUML、Columba、EMF、Hibernate、JEdit、JFreeChart、JMeter、JRuby 和 SQuirreL 十个开源项目的标记代码注释。数据集的详细描述如表 2 所示。这十个项目属于不同的应用领域，具有不同的贡献者数量、评论以及规模和复杂性。我们可以看到每个项目中只有一小部分SATD评论。

4.2 Evaluation Metrics

4.3 Parameters and Experimental Environment

在我们模型的 Bi-LSTM 组件中，层数为两层，隐藏单元数设置为 128，两个分支分别产生 256 个单元的输出。具有默认设置的adam优化器（除了learning速率配置为1e4）用于training。为了避免过度拟合，我们在每两层之间添加一个 dropout 层，drop 概率为 0.5。我们将 L2 损失权重设置为 5e-4。由于SATD和非SATD评论的不平衡分布，我们引入加权交叉熵损失作为损失函数。我们通过十个实验计算 Precision、Recall 和F1 分数的平均值，以估计模型的性能。实验在具有 64GB 内存和 RTX2080Ti GPU 的 Linux 系统（Ubuntu 16.04 LTS）上运行，通过利用深度学习库 PyTorch 实现。

5 实验结果

5.1 RQ1: Effectiveness of HATD

为了评估我们方法的有效性，我们应用 HATD 来研究 [7] 维护的十个项目，因为这十个项目已经提供了真实的事实。基于这十个项目，我们从两个方面评估HATD的性能：
• 项目内。对于每个项目，我们进行 10 折交叉验证来评估 HATD 的分类能力。特别是，我们首先将项目的评论平均划分为十个子集。然后，我们用九个评论子集来训练我们的模型，并利用它对评论的其余的子集进行分类。我们重复这个实验 10 次，以确保每个子集都被视为一个测试集。最终性能报告为十轮实验的平均分数。
• 跨项目。在这方面，我们还进行了十轮实验，每轮测试一个项目。具体来说，对于每个项目，我们基于其他九个项目训练我们的模型，并利用它来预测被测项目的所有评论。为简单起见，分类结果将直接附加到 testing 项目中，尽管分类模型是基于其他九个项目进行训练的。

表 3 展示了我们的方法 w.r.t 的实验结果。精度、召回率和 F1 分数指标。最好和最差的结果分别用粗体和下划线突出显示，差异非常显着。这一发现表明我们的方法可能对训练数据集很敏感。事实上，我们的方法对JEdit 项目产生了相对较差的性能，因为它的许多注释很短并且有时毫无意义（例如，“内部类”或“unsplit() 方法”），导致噪音或缺乏有效的语义信息通过我们的方法学习。此外，一些项目在项目内设置（例如，JFreeChart）中取得了更好的性能，而其他项目在跨项目设置（例如，JEdit）中取得了更好的性能，这一事实进一步证实了训练集的质量很重要我们的方法。

对 RQ1 的回答：我们的方法可以在项目内和跨项目设置中实现高性能，因此可有效且实用地用于确定实际软件项目的 SATD。

5.2 RQ2: Performance Comparison with the state-of-the-art Approach

对 RQ2 的回答：HATD 优于最先进的方法，包括基于神经网络的方法，例如 Ren 的方法和基于模式的方法，以及传统的基于文本挖掘的方法。

5.3 RQ3: Effectiveness of the selected word embedding technique

对 RQ3 的回答：ELMo 在支持基于神经网络的 SATD 检测时，通过实现最佳或次佳性能而优于其他词嵌入技术。此外，在相同的上下文中，动态词嵌入技术似乎比静态词嵌入技术更可靠。

5.4 RQ4: SATDs in real-world software projects

为了评估 HATD 的实用性，在最后一个研究问题中，我们评估了在多大程度上可以利用 HATD 来检测实际软件项目中的 SATD，这些项目没有预先构建ground truth。此外，我们还评估了 HATD 是否适用于其他编程语言，例如 Python、JavaScript 等。为此，我们借助 Github 搜索热门项目，最终选择了十个软件项目，采用不同的技术考虑的领域。表 6 总结了十个项目及其元数据，例如简短描述、总评论数等。

然后，我们根据十个基准应用程序（如表 2 中列举的）训练我们的方法，并将其应用于对上述十个实际软件项目中的每一个的评论进行分类。表 6 的最后第二列说明了实验结果。总共，在 382,799 条评论中，HATD 将其中 5,438 条标记为 SATD。所有项目评论中SATDs的比例很低，从0.7%到3.38%不等，平均为1.33%。与 ground truth 项目相比，我们观察到在我们选择的这十个真实世界的软件项目中，SATD 较少，这可能是因为它们在 Github 上非常受欢迎，并且更多的贡献者参与了代码提交和维护。这些软件项目中代码贡献者的平均数量是 ground truth 项目的十倍。

手动验证 HATD 报告的结果。我们从标记为有技术债务和无技术债务的代码注释中随机抽取 50 个样本（共 100 条注释）进行进一步分析。然后，我们邀请五位程序员手动判断这 100 条选定的评论，并将他们的决定与我们基于注意力的深度学习模型产生的结果进行比较。五名程序员手动将 100 条评论分别标记为 SATD 或非 SATD，然后在首先做出不一致的决定时相互讨论以达成共识。在标记为 SATD 的 50 条代码注释中，有 12 条没有被 5 位程序员标记为 SATD。在标记为 non-SATD 的 50 条代码注释中，只有 5 条注释与手动注释不同。总体而言，我们的方法在检测流行的现实世界软件项目中的 SATD 时的准确率为 83%。考虑到我们选择的实际项目来自不同的技术领域，具有显着的领域差异，我们的训练集（基于十个基准应用程序）不会完全覆盖一些领域特征。随着训练数据的增加，我们相信我们的模型的性能可以进一步提高。

对 RQ4 的回答：在实际场景中，我们的方法在检测真实软件项目中的 SATD 时达到了 83% 的准确率。所有选定的软件项目或多或少都涉及SATD的事实表明SATD通常在软件项目中传播。因此，我们认为软件开发人员和维护人员应该更加关注SATD。

6 DISCUSSIO

我们现在讨论我们的SATD检测方法的可解释性，并介绍本研究有效性的潜在威胁。

6.1 HATD 的可解释性

为了解释 SATD 分类的结果，Potdar 等人。 [38] 手动总结了 62 种常见的 SATD 模式，用于检测 SATD 评论。然而，这个手动过程既费时又费力，而且很难总结出所有的SATD模式。任等人。 [39]利用回溯机制将CNN提取的特征映射到关键h-gram，并将关键h-gram总结为SATD模式。然而，他们的方法需要回溯机制将提取的特征传播回模型的相同结构。
在这项工作中，我们提出了一种基于注意力的神经网络来检测和解释 SATD 分类。通过权重的可视化，我们发现我们的方法可以立即为每个评论提供单词级和短语级的可解释性，而不管项目差异和耗时的模式总结问题。

图 7 显示了我们检查过的两个评论示例。颜色阴影表示单词的注意力权重。注意权重越高，颜色越深。出于可视化目的，我们删除了填充词以确保只强调有意义的词。从图 7 中，我们可以看到我们的方法在第一条评论中突出显示了 hack 一词。在第二条评论中，我们的方法突出了 TODO 这个词和一个更好的短语。我们发现了一个有趣的现象，即关键字hack在第一条评论中带有明显的SATD趋势，这与第二条评论中的不同。这说明相同的关键词在不同的评论中对SATD检测会起到不同的作用，这进一步加剧了人工总结SATD模式识别SATD的难度。

此外，我们在表 7 中总结了 10 个开源项目中每一个的前 10 个 SATD 模式。有趣的是，我们可以观察到许多项目共享一些常见的一克SATD模式（下划线），例如“to do”、“xxx”、“fix”、“fixme”、“hack”、“work”、“perhaps” 、“解决方法”、“更好”和“错误”。同时，一些SATD模式只出现在一两个项目中。比如“apublic setter”只用在Apache Ant项目中，“model element”、“model/extent”和“behind addTrigger”只用在ArgoUML项目中，“programming error”和“tweak”只用在JMeter和JFreeChart项目中，分别。我们观察到 Potdar 等人没有发现一些模式（粗体）。和任等人。 [38,39]，表明手动总结SATD模式可能会遗漏一些证据不足的SATD模式，并且还会遇到项目差异的问题。我们的方法可以通过自动识别 SATD 并突出显示有助于此类识别的关键字或短语来补充这些作品，而不管项目差异如何。

6.2 Threats to Validity

内部有效性的威胁与我们实施中的错误和数据标签中的个人偏见有关。为了避免实施错误，我们仔细检查了我们的实验步骤和参数设置。为了避免手动标记代码注释的个人偏见，我们实验中使用的数据集具有很高的评分者间一致性（Cohen 的 Kappa 系数为 0.81），这已由 Maldonado 等人报道。 [31]。另外，我们没有使用[7]提出的细粒度SATD类别，只考虑代码注释的二进制分类。换句话说，设计债、需求债、缺陷债、文档债和测试债都被简单地视为SATD。

外部有效性的威胁与我们实验数据集的数量和质量以及我们的实验结果和发现的普遍性有关。为了保证我们数据集的数量和质量，我们考虑了十个不同功能和领域、不同评论数量和评论特征的开源项目。为了保证我们的实验结果和发现的普遍性，我们从 Github 爬取了另外十个流行的软件项目来测试我们训练好的模型。通过手动验证我们的方法报告的结果，我们得出结论，我们的方法在 100 条随机选择的评论上达到了 83% 的准确率。

7 相关工作

自我承认的技术债务 (SATD) 是技术债务的一种变体，用于识别在软件开发过程中有意引入的债务。 SATD的检测可以更好地支持软件维护并确保高软件质量[9,17,22,26,28,29,33]。本文旨在提出一种基于深度学习的方法来检测SATD。据我们所知，关于使用深度学习技术进行SATD检测的研究非常有限。因此，我们将相关工作分为两个主要部分：代码注释分析、SelfAdmitted Technical Debt 中的现有研究。

7.1 代码注释分析

代码注释在软件开发中扮演着重要的角色。注释的意义在于使开发人员能够轻松理解和管理代码[15,42,49]。代码注释通常以自然语言文本编写，包含功能描述和任务注释，旨在辅助项目开发。由于开发者、项目和编程语言的不同，代码注释会有不同的特点。

许多研究调查了代码注释的特征。 Fluri 等人。 [11] 调查了开发人员在三个开源系统中演化代码时添加评论或调整评论的水平。结果他们发现，当相关代码发生变化时，注释的变化通常是在同一个版本中进行的。 Steidl 等人。 [44] 和孙等人。 [46] 进行了代码注释质量分析，以提高代码注释的质量。更具体地说，Steidl 等人。提供一种半自动化的方法来对评论质量进行定量和定性评估。孙等人。扩展了他们的工作并提供了更准确和全面的评论评估和建议。

7.2 自我承认的技术债务研究

目前，许多研究人员专注于提出检测和管理技术债务的方法。事实上，许多实证研究已应用于技术债务 [1, 24, 40,61-63]。 Potdar 等人[38] 提出了自我承认技术债务（SATD）的概念。 SATD 意味着债务是有意引入并由开发人员在代码注释中报告的。他们手动总结了来自不同 Java 项目的 62 种特定模式，用于检测 SATD 注释。威海比等。 [52] 研究了 SATD 和软件缺陷之间的关系，发现 SATD 导致软件系统在未来消耗更多的资源，而不是等同于软件缺陷。根据SATD评论的不同特点，Maldonado等人。 [31]进一步将SATD分为五种类型，即设计债务、缺陷债务、文件债务、需求债务和测试债务。

近年来，软件工程领域的研究人员为解决SATD检测问题做出了重大努力[7,8,32,57]。黄等人[16]提出了一种基于文本挖掘的SATD检测方法。在他们的工作中，他们利用特征选择器为分类器训练选择有用的特征，并根据来自不同源项目的分类器投票结果检测目标项目中的 SATD 评论。马尔多纳多等人。 [7] 构建了一个最大熵分类器，用于基于自然语言处理 (NLP) 技术自动识别设计和需求 SATD 注释。他们在 10 个开源项目中进行了广泛的实验，并在基于固定关键字和短语的情况下超越了当前最先进的技术。严等人。 [55] 提出了一种利用 25 个变化特征进行 SATD 检测的变化级别方法。此外，他们还研究了影响 SATD 检测的最重要特征（“扩散”）。

随着深度学习的快速发展，Ren 等人。 [39]利用基于深度学习的方法作为SATD检测的支持。在他们的工作中，他们利用卷积神经网络 (CNN) 来自动学习 SATD 评论中的关键特征。他们引入了加权损失函数来处理数据不平衡的问题。此外，为了检测的可解释性，他们设计了一种回溯方法来提取和突出SATD评论的关键短语和模式，以解释预测结果。

8 总结

这项工作的目的是自动检测和解释软件项目中自我承认的技术债务，使软件开发人员能够及时修复这些问题，从而避免长时间的维护工作。为了实现这一目标，在这项工作中，我们提供了代码注释特征的概述，这些特征使得自动检测 SATD 具有挑战性。然后，我们向社区提出了一种名为 HATD 的基于混合注意力的 SATD 检测方法，该方法具有根据项目唯一性和评论特征切换词嵌入技术的灵活性。之后，我们通过（1）在基准数据集上优于最先进的方法，（2）在现实世界的软件项目中检测 SATD，以及（3）证明 HATD 在突出显示方面的可解释性，通过实验证明了 HATD 的效率核心词或短语证明为什么给定的SATD被标记为这样。

REFERENCES

https://doi.org/10.1145/3324884.3416583

Detecting and Explaining Self-Admitted Technical Debts with Attention-based Neural Networks相关推荐

基于激活聚类的后门检测：Detecting Backdoor Attacks on Deep Neural Networks by Activation Clustering
Detecting Backdoor Attacks on Deep Neural Networks by Activation Clustering 网址:https://arxiv.org/abs ...
Explaining Deep Neural Networks
Explaining Deep Neural Networks 翻译一下牛津小姐姐这这篇优秀的博士论文,可以大致当做一篇综述来看,如果有翻译不好的地方,请大家多多指点附上论文地址 https://a ...
A novel framework for detecting social bots with deep neural networks and active learning（SCI一区）
目录摘要 1 绪论 1.1. Social bots in OSNs 1.2. Challenges 1.3. Contribution and organization 2 相关工作 2.1. G ...
[paper]Feature Squeezing: Detecting Adversarial Examples in Deep Neural Networks
本文提出了两种特征压缩方法: 减少每个像素的颜色位深度使用空间平滑来减少各个像素之间的差异特征压缩通过将与原始空间中许多不同特征向量相对应的样本合并为单个样本,从而减少了对手可用的搜索空间.通过将 ...
ICCV 2021 最新200篇ICCV2021论文分方向汇总
ICCV 2021 结果出炉!最新200篇ICCV2021论文分方向汇总(更新中) - 知乎不久前,计算机视觉三大顶会之一ICCV2021接收结果已经公布,本次ICCV共计 6236 篇有效提交论文 ...
Paper：LIME之《Why Should I Trust You? Explaining the Predictions of Any Classifier为什么要相信你?解释任何分类器的预测》翻
Paper:LIME之<Why Should I Trust You? Explaining the Predictions of Any Classifier为什么要相信你?解释任何分类器的预 ...
Detecting Faces in Images: A Survey( 翻译）
IEEE TRANSACTIONS ON PATTERN ANALYSIS AND MACHINE INTELLIGENCE, VOL. 24, NO. 1, JANUARY 2002 Detecti ...
CTPN模型详解--Detecting Text in Natural Image with Connectionist Text Proposal Network
文章目录 Abstract 1 Introduction 1.1 Contributions 2 Related Work 3 Connectionist Text Proposal Network ...
Machine Learning for Technical Debt Identification
目录 Abstract: 1 INTRODUCTION 2 RELATED WORK 3 METHODOLOGY 3.1 Data Collection 3.1.1 Project Selection ...

Detecting and Explaining Self-Admitted Technical Debts with Attention-based Neural Networks

摘要