[论文解读] Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

Laerte Xavier, Fábio Ferreira+2 more|arXiv (Cornell University)|Mar 20, 2020

Software Engineering Research被引用 7

一句话总结

本文提出了基于问题的自述技术债（SATD-I），即开发人员通过在问题追踪系统中使用诸如“技术债”等标签，显式地记录技术债，而非在源代码注释中记录。通过对五个开源项目中286个SATD-I实例的分析，研究发现仅有29%的SATD-I实例也存在于代码注释中，且这些实例的关闭时间更长，尽管代码变更量相似，其中45%的实例为尽早发布而引入，60%与设计缺陷相关。研究结果呼吁开发支持基于问题的技术债跟踪与管理的工具。

ABSTRACT

Self-admitted technical debt (SATD) is a particular case of Technical Debt (TD) where developers explicitly acknowledge their sub-optimal implementation decisions. Previous studies mine SATD by searching for specific TD-related terms in source code comments. By contrast, in this paper we argue that developers can admit technical debt by other means, e.g., by creating issues in tracking systems and labelling them as referring to TD. We refer to this type of SATD as issue-based SATD or just SATD-I. We study a sample of 286 SATD-I instances collected from five open source projects, including Microsoft Visual Studio and GitLab Community Edition. We show that only 29% of the studied SATD-I instances can be tracked to source code comments. We also show that SATD-I issues take more time to be closed, compared to other issues, although they are not more complex in terms of code churn. Besides, in 45% of the studied issues TD was introduced to ship earlier, and in almost 60% it refers to Design flaws. Finally, we report that most developers pay SATD-I to reduce its costs or interests (66%). Our findings suggest that there is space for designing novel tools to support technical debt management, particularly tools that encourage developers to create and label issues containing TD concerns.

研究动机与目标

• 调查自述技术债（SATD）是否在源代码注释之外的其他地方被记录，特别是问题追踪系统中。
• 理解现实世界软件项目中基于问题的SATD（SATD-I）的特征、成因及动机。
• 探讨记录在代码注释中的技术债（SATD-C）与记录在问题中的技术债（SATD-I）之间的重叠情况。
• 识别开发人员引入和偿还SATD-I的原因，并评估此类技术债对项目维护的影响。

提出的方法

• 通过识别包含‘技术债’或‘debt’等术语标签的问题，从五个开源项目（包括Microsoft Visual Studio和GitLab）中收集了286个SATD-I实例。
• 使用最先进的工具SATDDetector检测同一项目中基于代码的自述技术债（SATD-C），以与SATD-I进行对比。
• 研究人员将SATD-I实例手动分类为文献中列出的十个技术债类别，重点关注设计缺陷和代码重复等类型。
• 对30名参与偿还SATD-I的开发人员进行了调查，以理解其引入和解决技术债的动机。
• 通过测量代码变更量来评估SATD-I与非SATD问题之间的复杂性差异，确保关闭时间的差异并非由更高复杂度导致。
• 本研究采用定性和定量分析方法，比较SATD-I与SATD-C，并分析技术债引入与偿还背后的原因。

实验结果

研究问题

• RQ1 RQ1：在所研究的项目中，基于代码的SATD（SATD-C）与基于问题的SATD（SATD-I）实例之间重叠程度如何？
• RQ2 RQ2：在SATD-I实例中，哪些类型的技术债最常被偿还？
• RQ3 RQ3：开发人员为何在项目中引入SATD-I？
• RQ4 RQ4：开发人员为何选择偿还SATD-I，其背后的动机是什么？

主要发现

• 在所研究的286个SATD-I实例中，仅有29%也记录在源代码注释中，表明相当大一部分自述技术债存在于代码库之外。
• SATD-I实例的关闭时间显著长于其他问题，尽管其代码变更量相似，表明这些实例并非更复杂，但可能涉及更深层次的设计或架构考量。
• 在45%的情况下，技术债的引入是为了实现更早的软件交付，凸显时间压力在技术债积累中的作用。
• 在近60%的SATD-I实例中，技术债与设计缺陷相关，其中44%具体涉及方法级别的设计问题，如代码重复或内聚性差。
• 偿还SATD-I最常见的动机是降低利息成本（44%）和保持代码的整洁与可维护性（33%），表明开发人员对长期维护负担有清晰认知。
• 本研究证实，开发人员积极利用问题追踪系统来记录和管理技术债，表明基于问题的跟踪是技术债管理中一种可行且尚未被充分利用的渠道。