Identification and Remediation of Self-Admitted Technical Debt in Issue Trackers
技术债是指为了实现短期目标而采取的捷径，这可能会对长期的软件维护产生负面影响。开发人员在源代码注释中承认的技术债（称为自承技术债或SATD）越来越受到关注。但问题跟踪器中的SATD相对未被探索。我们进行了一个案例研究，我们手动检查了来自两个开源项目（即Hadoop和Camel）的500个问题，其中包含152个SATD项目。我们发现：1）问题中的技术债分为8种类型，即架构债、构建债、代码债、缺陷债、设计债、文档债、需求债和测试债; 2）开发人员在3个不同的时间点上识别问题中的技术债，一小部分是由其创建者识别的; 3）大部分技术债是由识别或创建技术债的人偿还的; 5）偿还技术债务的时间中位数和平均时间分别为872.3小时和25.0小时。
2020-08-29 cs.SE
The use of incentives to promote Technical Debt management
在开发软件时，保持技术债务的水平是至关重要的，因为从几项研究中可以很好地确定技术债务可以，例如，降低了开发效率，降低了开发人员的士气，并损害了软件的整体质量。然而，即使在今天的软件开发行业的研究人员和从业人员都非常熟悉的概念，技术债务及其相关的负面影响，一直没有实证研究，特别是软件管理人员如何积极沟通和管理的需要，以保持尽可能低的技术债务水平。
2021-01-05 cs.SE
Measuring the Impact of Technical Debt on Development Effort in Software Projects
本研究针对软件项目中技术债务影响开发效率的问题，结合开源与企业项目数据实证分析技术债务带来的额外工作量及推迟偿还的长期影响，提出技术债务管理框架以助力相关人员管控其对生产力和成本的影响。
2025-02-22 cs.SE
Can Clean New Code reduce Technical Debt Density?
虽然随着软件系统的发展，技术债务的绝对数量会增加，但在某些情况下，技术债务的密度（技术债务除以代码行）会降低。这可以通过重构的应用或开发具有有限技术债务的新工件来解释。本文通过考察新法规中的技术债务数额与技术债务在制度中的演变之间的关系，探讨了第二种解释。为此，我们将新代码与现有代码的技术债务密度进行比较，并调查三种主要类型的代码更改（添加，删除和修改）中的哪一种主要负责技术债务密度的演变。此外，我们研究是否有代码质量的做法和新代码的“清洁”之间的关系。为了获得所需的数据，我们对Apache软件基金会的27个开源软件项目进行了大规模的案例研究，分析了66，661个类和56，890个提交。结果表明，编写“干净”（或至少“干净”）的新代码可以是降低技术债务密度的有效策略，从而防止软件随着时间的推移而衰退。研究结果还表明，采用明确的质量改进政策的项目，例如通过在董事会会议上讨论代码质量，与更干净的新代码提交频率较高有关。因此，我们倡导建立监控新代码的技术债务密度的过程，以控制软件系统中技术债务的积累。
2020-10-19 cs.SE
Business-Driven Technical Debt Prioritization: An Industrial Case Study
从业务角度出发，优先考虑技术债务，这对行业决策至关重要。在本文中，我们发展和评估业务驱动的方法，技术债务优先级。在商业和技术利益攸关方的积极参与下，在为期五个月的工业案例研究中对这一方法进行了评估。结果表明，该方法有助于调整业务和技术利益相关者之间的业务标准。我们还观察到影响高价值业务资产的技术债务数量呈下降趋势。此外，我们确定了八个影响技术债务优先级相关决策的业务因素。研究结果表明，提出的业务驱动的技术债务优先级排序方法可以帮助团队集中精力偿还业务最相关的债务。
2021-03-22 cs.SE
Measuring Technical Debt in AI-Based Competition Platforms
本文通过范围综述识别并分类AI竞赛平台中的技术债务类型，提出专门的可访问性债务概念，并开发问卷与管理框架以提升平台的可持续性和可维护性。
2024-08-01 cs.SE
Debt-Prone Bugs: Technical Debt in Software Maintenance
修复bug是软件开发和维护的一个重要阶段。在实践中，bug修复的过程可能会与发布时间表相冲突。这种冲突导致了软件质量和发布进度之间的权衡，这被称为技术债务隐喻。在这篇文章中，我们提出了债务倾向的错误的概念，在软件维护中的技术债务模型。我们确定了三种类型的债务倾向的错误，即标签错误，重新打开的错误，和重复的错误。对Mozilla进行了案例研究，以检查软件产品中容易产生债务的错误的影响。我们调查债务倾向的错误和产品质量之间的相关性。对于正在开发的产品，我们基于历史产品构建预测模型来预测修复错误的时间成本。结果表明，识别债务倾向的错误可以帮助监控和提高软件质量。
2017-04-16 cs.SE
Long-Term Evaluation of Technical Debt in Open-Source Software
现有的软件工具能够在选择的粒度级别上表征和测量技术债务的数量。本文旨在研究开源软件中技术债的演变和特征。我们进行了一项纵向研究，涵盖了几个复杂应用程序的整个开发历史。我们研究了技术债务是如何引入软件的，以及确定开发人员如何处理其长期积累。我们使用三个复杂的开源Java应用程序进行了评估。使用SonarQube分析了所有110个已发布的版本，涵盖了每个应用程序超过10年的开发历史。我们研究了技术债务的数量、组成和历史在开发过程中的变化，比较了我们在研究应用中的结果，并提出了我们最重要的发现。对于每个应用程序，我们都确定了关键版本，在此期间，大量的技术债务被添加，删除或两者兼而有之。与开发期间通常发生的代码行或类计数增加相比，这具有更大的影响。在每个版本中，我们发现文件代码行和技术债务之间存在高度相关性。我们观察到，帕累托原则是满意的研究应用程序，因为20%的问题类型产生了约80%的总技术债务。早期的应用程序版本显示，现有技术债务的金额波动较大。应用程序的大小似乎是一个不可靠的预测技术债务的数量。大多数债务是作为扩展其功能集的里程碑版本的一部分引入应用程序的。我们还发现，技术债务问题在源代码中持续存在很长一段时间，并且它们的删除似乎没有根据类型或严重程度进行优先级排序。
2020-07-27 cs.SE
Examination of tools for managing different dimensions of Technical Debt
由于市场上有许多免费增值和高级，开源和闭源软件工具可用于处理不同维度的技术债务管理的不同活动，因此为特定活动和维度确定正确的工具集可能非常耗时。新时代的云优先工具更容易上手，而传统工具在让用户知道它能提供什么之前需要相当长的时间。此外，由于许多工具只处理诸如代码和测试债务等技术债务的几个维度，因此为其他维度（如设计、架构、文档和环境债务）识别和选择正确的工具可能会很累。我们试图通过展示我们的发现来减少这个令人厌倦的过程，这些发现可以帮助那些进入“软件开发中的技术债务”领域并随后进一步进入“技术债务管理”领域的人。
2019-04-24 cs.SE
Measuring affective states from technical debt: A psychoempirical software engineering experiment
软件工程是一项人类活动。尽管如此，在技术债务研究中，人的方面的代表性不足，也许是因为他们具有挑战性的评估。本研究的目的是调查软件从业人员的技术债务和情感状态（感觉，情绪和心情）之间的关系。来自12家公司的40名参与者（N = 40）参加了混合方法的研究，包括重复测量（r = 5）实验（n = 200），调查和半结构化访谈。统计分析表明，不同的设计气味（技术债务的强烈指标）对情感状态产生负面或正面的影响。从定性数据来看，很明显，技术债务激活了情绪频谱的很大一部分，并且在心理上是负担。此外，从业者对技术债务的反应似乎在不同的成熟度水平上下降。我们认为，技术债务中的人为因素是需要考虑的重要因素，因为它们可能导致，例如，拖延、忧虑和倦怠。
2021-05-02 cs.SE
Analyzing the Rework Time and Severity of Code Debt: A Case Study Using Technical Debt Catalogs
本文介绍了一个分析Hibernate生态系统软件项目的案例研究，以调查和展示与严重性和返工时间相关的代码债行为。通过案例研究发现，严重程度与软件维护影响相关的代码债是Hibernate生态系统中最具代表性的，需要支付的返工次数也最多。此外，它被发现的分布返工时间的代码债的所有严重程度经历的变化，在最初的版本的发展。
2020-02-11 cs.SE
Comments or Issues: Where to Document Technical Debt?
本文调查了190个GitHub项目中74K条SATD-C和20K条SATD-I实例的作者，探究开发者选择用注释或议题记录技术债务的动因，并提出了13条指南以辅助决策。
2024-08-27 cs.SE
The Influence of Cognitive Biases on Architectural Technical Debt
本研究通过半结构化访谈软件架构师，分析认知偏差如何及何时引发架构技术债务，并提出去偏技术与组织文化的防范作用。
2023-09-25 cs.SE
The Nature of Technical Debt in Research Software
University of Victoria（维多利亚大学）；IIT Palakkad（印度理工学院帕拉克卡德分校）；University of Oklahoma（俄克拉荷马大学）
本文研究了研究软件中技术债的性质与影响，通过分析28k条代码注释和访谈，识别出九种独特技术债类型及四个影响主题。
2026-03-20 cs.SE
WeakSATD: Detecting Weak Self-admitted Technical Debt
加速发展可能会产生技术债务，即，不完全正确的代码，使其正确的努力随着时间的推移而增加，这是一种兴趣。开发人员可能会意识到债务，因为他们在代码注释中承认了这一点。文献报道，这种自我承认的技术债务在程序中存在很长一段时间，但目前还不清楚其对代码质量的长期影响。我们认为，自我承认的技术债务包含了一些不同的弱点，可能会影响程序的安全性。因此，债务不偿还的时间越长，弱点被利用的风险就越高。为了讨论我们的主张并提高开发人员对未偿还的自我承认的技术债务的脆弱性的认识，我们探索了Chromium C代码中的自我承认的技术债务，以检测任何已知的弱点。在这个初步的研究中，我们首先挖掘常见的弱点枚举存储库来定义自动检测和修复弱代码的算法。然后，我们解析C代码，以找到自我承认的技术债务和它所引用的代码块。最后，我们使用分析来发现与自我承认的技术债务相关的弱代码片段，并向开发人员推荐潜在的缓解措施。这些知识可以用来优先考虑自我承认的技术债务进行修复。已经开发了一个原型并应用于Chromium代码。初步研究结果表明，55%的技术债务代码包含14种不同类型的弱代码。
2022-05-04 cs.SE
Estimation and Prediction of technical debt: a proposal
技术债务是一个隐喻，用来表达这样一种想法，即在设计和构建软件时，以“快速而肮脏”的方式做事会导致越来越多的延迟未来费用。与金融债务类似，技术债务要求以额外发展努力的形式支付利息，如果没有做出快速和肮脏的设计选择，这种额外发展努力本可以避免。技术债适用于软件开发的所有方面，从最初的需求分析到部署和软件演化。从科学和工业的角度来看，技术债务正变得非常普遍。特别是，近年来相关论文的数量有所增加。相关工具的数量以及在行业中的采用也在增加，特别是因为技术债务非常昂贵，因此需要管理。然而，估计技术债务的技术是不充分的，因为它们主要集中在需求，代码和测试上，而忽略了关键的工件，如软件架构和软件使用的技术。此外，尽管其高度相关性，技术债务预测是技术债务的最少探索的方面之一。为了解决这些缺点，我必须进行研究：1）改进现有技术以正确估计技术债务; 2）确定使用预测技术来预测并避免技术债务的程度可以帮助公司节省资金并避免未来几年的潜在破产。拟议中的研究可以通过帮助公司节省数百万美元来产生重要的经济影响。它可以产生重大的科学影响，导致关键的发现，将通过专利，著名的科学期刊和会议传播。
2019-03-30 cs.SE
Refactoring Debt: Myth or Reality? An Exploratory Study on the Relationship Between Technical Debt and Refactoring
为了满足项目时间表或预算限制，开发人员故意偏离编写最佳代码的可行性代码，这被称为招致技术债务（TD）。此外，作为计划纠正的一部分，开发人员将这些缺陷记录为代码中的注释（即，自我承认的技术债务或SATD）。作为提高源代码质量的一种手段，开发人员经常对代码库应用一系列重构操作。在这项研究中，我们探讨开发人员偿还这种债务，通过重构操作，检查发生的SATD删除76个开源Java系统的代码。我们的研究结果表明，TD支付通常发生在重构活动中，开发人员出于特定原因重构代码以删除TD。我们设想我们的研究结果支持供应商提供工具，以更好地支持开发人员自动偿还技术债务。
2022-03-10 cs.SE
Business-Driven Technical Debt Prioritization
当团队在软件开发上走捷径以获得短期利益，代价是使未来的更改更加昂贵时，就会发生技术债务。以前的结果表明，技术专业人员所做的优先级排序和业务人员所期望的优先级排序之间存在不一致。本文提出了一种业务驱动的方法来确定技术债务项目的优先级。研究分为四个阶段：探索性，以确定研究重点;概念验证，在多案例研究中评估所提出的方法;解决方案，进行设计科学研究，以开发Tracy，技术债务优先级的框架;和验证。到目前为止的结果表明，业务驱动的技术债务项目的优先级可以改善技术和业务利益相关者之间的协调和沟通。
2019-08-01 cs.SE
Wait For It: Identifying "On-Hold" Self-Admitted Technical Debt
自我承认的技术债务是指软件开发人员知道他们当前的实现不是最佳的，并使用源代码注释来表明这一点的情况。在这项工作中，我们假设有可能开发自动化技术来更详细地理解这些评论的子集，并提出工具支持，可以帮助开发人员更有效地管理自我承认的技术债务。基于对335条表明自我承认的技术债务的评论的定性研究，我们首先确定了一种适合自动化管理的特定债务类别：“搁置”自我承认的技术债务，即，债务，它包含一个条件，指示开发人员正在等待某个事件或已在其他地方实现的更新功能。然后，我们设计和评估一个自动分类器，它可以识别这些“等待”的情况下，在0.83的接收器工作特征曲线（AUC）的面积，以及检测开发人员正在等待的特定条件。我们的工作是迈向自动化工具支持的第一步，它能够指示何时可以解决某些自我承认的技术债务。
2019-10-21 cs.SE
Gamification: a Game Changer for Managing Technical Debt? A Design Study
内容：技术债务管理对于软件工程师来说是一个挑战，因为他们缺乏工具支持，并且缺乏关于如何优先考虑技术债务偿还和预防活动的知识。此外，当有大量积压的债务，开发人员往往缺乏动力，以解决it.Objective：在本文中，我们描述了一个设计研究，探讨如何游戏化可以支持技术债务管理在一个大型的遗留软件系统的工业公司。我们的研究导致了一种新的工具（名为Themis），它结合了技术债务支持，版本控制和游戏化功能。除了游戏化功能外，Themis还为开发人员提供了将精力集中在哪里的建议，并为管理人员提供了跟踪技术债务活动的可视化。方法：我们描述了Themis是如何在与该公司的迭代部署中进行改进和验证的，最后进行了定性研究，以调查Themis的功能如何影响技术债务管理行为。我们考虑了对开发人员和管理人员的影响。结果：我们的研究结果表明，它实现了增加开发人员的动机，并支持管理人员在监控和影响开发人员的行为。我们展示了我们的研究结果如何通过提出如何应用游戏化的指导方针转移到其他环境中。结论：在这种情况下，游戏化似乎是一个很有前途的解决方案，以帮助技术债务管理，虽然它需要仔细设计和实施，以避免其可能的负面影响。
2018-02-08 cs.SE
Tracy: A Business-driven Technical Debt Prioritization Framework
技术债是软件开发中普遍存在的问题。软件开发团队必须优先考虑债务项目，并确定他们是否应该在任何时候解决债务或开发新功能。本文介绍了“特雷西”，一个框架，优先级的技术债务使用业务驱动的方法建立在业务流程之上。当前阶段的建议框架是在设计科学研究的第三阶段，这通常是分为探索，工程和评估阶段的开始。勘探和工程阶段有来自三家公司12个不同小组的49名专业人员参加。初步评估表明，所提出的框架是一致的，其结构和结果有助于业务驱动的决策技术债务优先级。
2019-07-31 cs.SE
Architectural Archipelagos: Technical Debt in Long-Lived Software Research Platforms
本文确定了一个模型的软件演化，是普遍存在于大型，长期的学术研究工具套件（3L-ARTS）。这种模式导致了一个“群岛”的相关，但随意组织的架构“岛屿”，并内在地诱导技术债务。我们说明了群岛模型与文献中确定的两个3L-ARTS群岛的例子。
2021-04-17 cs.SE
Technical Debt Prioritization: State of the Art. A Systematic Literature Review
背景软件公司需要管理和重构技术债务问题。因此，有必要了解重构技术债务是否以及何时应该优先于开发功能或修复错误。Objective.本研究的目的是调查现有的知识体系在软件工程，以了解技术债务优先级的方法已被提出在研究和工业。法我们对截至2018年发表的384篇独特论文进行了系统性文献综述，遵循软件工程中应用的综合方法。我们纳入了38项主要研究。结果已经提出了不同的方法来确定技术债务的优先次序，所有这些方法都有不同的目标和不同的标准。拟议的措施只捕捉了在实践中用于定性地确定技术债务优先次序的众多因素中的一小部分。我们报告了这些因素的影响图。然而，缺乏一套经验性的、经过验证的工具。结论我们注意到，技术性的债务优先级研究是初步的，在什么是重要因素以及如何衡量这些因素方面没有达成共识。因此，我们不能认为目前的研究结论，在本文中，我们概述了必要的未来调查的不同方向。
2020-01-30 cs.SE
Faster Code, Deeper Debt? A Multivocal Literature Review on Technical Debt and Its Early Signs in LLM-Assisted Software Development
Drexel University（德雷塞尔大学）
通过104篇文献的多声部综述，发现LLM辅助开发放大传统技术债务（代码、设计、文档债务）并引入新债务（快速集成、提示、伦理、数据、来源债务），提出人机协同、提示工程等缓解策略，但缺乏标准化基准。
2026-06-16 cs.SE
Does Migrate a Monolithic System to Microservices Decrease the Technical Debt?
背景从单体系统到微服务的迁移涉及系统的深度重构。因此，迁移通常会产生很大的经济影响，公司往往会在此过程中推迟几项活动，主要是为了加快迁移本身，但也是因为需要发布新功能。Objective.我们监测了一家中小型企业的技术债务，同时将一个遗留的单片系统迁移到微服务生态系统，以分析迁移到微服务之前和之后代码技术债务的变化。法我们进行了一个案例研究，分析了一个大项目（28万行代码）四年多的历史，其中两个团队从整体系统中提取了五个业务流程作为微服务，首先使用SonarQube分析技术债务，然后与开发人员进行定性研究，以了解系统的感知质量和最终推迟活动的动机。结果.从长远来看，微服务的发展有助于减少技术债务。尽管由于新微服务的发展，技术债务最初出现了峰值，但在相对较短的时间内，技术债务的增长速度往往比单片系统慢。
2020-07-04 cs.SE
A Framework for Conditional Statement Technical Debt Identification and Description
当开发团队更喜欢短期的可操作性而不是长期的稳定性时，就会出现技术债务。由于这将软件的可维护性置于风险之中，技术债务需要尽早关注，以避免支付累积的利息。现有的大多数工作都集中在使用代码注释来检测技术债务，称为自承认技术债务（SATD）。然而，在许多情况下，技术债务实例并没有被明确承认，而是深深隐藏在代码中。在本文中，我们提出了一个框架，迎合了没有SATD注释的代码。我们的自承认技术债务识别和描述（SATDID）框架确定是否应该为输入代码片段自承认技术债务。如果是这种情况，SATDID将自动生成可以附加到代码中的适当的描述性SATD注释。虽然我们的方法原则上适用于任何类型的代码片段，但在这项研究中，我们专注于隐藏在条件语句中的技术债务，这是代码中最具TD的部分之一。我们探索和评估SATDID的不同实现。评估结果表明，我们的框架在多个基准的适用性和有效性。与基准测试的结果相比，我们的方法提供了至少21.35%，59.36%，31.78%，和583.33%的精度，召回，F-1和蓝-4分数，分别提高。此外，我们对SATDID生成的SATD评论进行人工评估。在可接受性和可理解性的1-5和0-5量表中，通过我们的方法实现的总平均值分别为3.128和3.172。
2022-10-13 cs.SE
Exploration of technical debt in start-ups
通过对86个初创企业案例的调查，发现测试维度技术债务最严重，团队规模与经验是主要先例，需预先监控和控制技术债务。
2023-09-21 cs.SE
Towards Surgically-Precise Technical Debt Estimation: Early Results and Research Roadmap
技术债务的概念已经从许多角度进行了探讨，但其准确的估计仍然是在大量的经验和实验调查。我们的目标是了解，通过利用近似的、数据驱动的、机器学习的方法，是否有可能改进当前的技术债务估计技术，如SonarQube等顶级行业质量分析工具所代表的。为了简单起见，我们专注于相对简单的回归建模技术，并将其应用于模拟与研究中的项目中存在的次优条件相关的额外项目成本。我们的研究结果表明，目前的技术可以改善对技术债务的更精确的估计和案例研究表明，有前途的结果对识别更准确的估计技术债务。
2019-08-02 cs.SE
From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI
University of Victoria（维多利亚大学）
本文提出三债务模型，探讨生成式AI如何改变软件健康中技术、认知和意图债务的相对重要性及应对方法。
2026-04-06 cs.SE
An insight into the technical debt-fix trade off in software backporting
University of Saskatchewan（萨斯喀彻温大学）
本研究分析三个软件生态系统87个仓库的向后移植数据，发现约4.3%的向后移植引入技术债务，不同生态系统债务分布阶段及开发者因素存在差异，揭示了稳定版本向后移植中技术债务产生的规律。
2025-11-12 cs.SE
Technical Debt Management: The Road Ahead for Successful Software Delivery
本文调研了产业界与研究界的技术债务管理现状，梳理实践缺口与研究不足，提出未来五年技术债务管理的发展愿景，为软件系统的长期健康交付提供方向指引。
2024-03-11 cs.SE
Technical Debt: Identify, Measure and Monitor
技术债务（Technical Debt）是由Ward Cunningham提出的一个术语，用来表示将一个软件置于它从最早开始就应该具有的状态所需的调整措施。通常，组织需要从短期和长期的角度支持持续快速地交付客户价值，然后不得不在软件的质量和生产力方面做出妥协。因此，一个简单的解决方案可能是在遇到债务时偿还债务，以避免可维护性成本和随后的延迟。因此，不可避免地要确定和提出技术，以便知道何时、如何偿还TD项目。本研究旨在探讨如何识别，测量和监测技术债务使用SonarQube和PMD。
2019-10-28 cs.SE
The Technical Debt Gamble: A Case Study on Technical Debt in a Large-Scale Industrial Microservice Architecture
本研究通过混合方法案例研究，揭示大规模微服务系统中技术债务的表现，提出静态分析可高效发现债务，并指出沟通不足与架构组织错位加剧债务，总结出管理策略。
2025-06-19 cs.SE
Preventing technical debt with the TAP framework for Technical Debt Aware Management
上下文技术债务（TD）是一个比喻，指用户和客户看不到的技术问题，但会阻碍开发人员的工作，使未来的更改更加困难。TD通常是由于项目的最后期限紧迫而产生的，并且可能使未来的更改成本更高或不可能。项目管理通常关注客户利益，而不太关注IT系统的内部质量。TD预防应优先于TD偿还，因为随后的重构和重新设计是昂贵的。Objective.本文评估了一个框架，侧重于TD预防和TD偿还的背景下，敏捷管理的项目。该框架的开发和应用在一个出版社的IT部门。该框架的独特贡献是将TD管理纳入项目管理。法评价是作为一个比较案例研究的基础上门票统计和两个结构化的调查。调查是在使用框架的观察IT单位和不使用框架的比较单位进行的。第一项调查针对的是团队成员，第二项调查针对的是IT经理。结果评价表明，在该信息技术单位，技术咨询方案框架提高了对贸易发展问题的认识。产生TD的决定是有意的，TD的偿还更及时。由无意识的决定引起的无意TD被防止。此外，还可以看到更好的沟通和更好的项目管道规划。结论.我们提供了一个深入了解从业者的方式来识别，监测，预防和偿还TD。所提出的框架包括一个可行的方法，防止TD尽管紧迫的时间表，使TD偿还项目管理的一部分。
2022-04-20 cs.SE
DebtViz: A Tool for Identifying, Measuring, Visualizing, and Monitoring Self-Admitted Technical Debt
针对自承认技术债务（SATD）综合管理工具匮乏的问题，本文提出DebtViz工具，采用卷积神经网络检测、反卷积提取关键词，具备检测分类、可视化监控等功能，可提升SATD管理效率并支持知情决策，适用于多种开发环境。
2023-08-25 cs.SE
Systematic literature review on forecasting and prediction of technical debt evolution
本文通过系统性综述646篇论文并分析14项主要研究，梳理技术债务演化预测方法，发现随机森林与时间卷积网络表现较优但仅覆盖代码和架构债务。
2024-06-17 cs.SE
The Technical Debt Dataset
技术债分析越来越受欢迎，因为现在的研究人员和行业正在采用各种静态代码分析工具来评估他们的代码质量。尽管如此，软件项目的实证研究是昂贵的，因为需要时间来分析项目。此外，由于研究通常考虑不同的项目，因此很难比较结果。在这项工作中，我们提出了技术债务数据集，这是一组来自Apache软件基金会的33个Java项目的项目测量数据。在Technical Debt Dataset中，我们使用SonarQube分析了单独定义的时间范围内的所有提交，以收集Technical Debt信息，并使用Ptidej检测代码气味。此外，我们从git日志中提取了所有可用的提交信息，使用Refactoring Miner应用的重构，以及问题跟踪器（Jira）中报告的错误信息。使用这些信息，我们执行SZZ算法来识别错误诱导和修复提交。我们分析了来自选定的33个项目的78K提交，检测到180万个SonarQube问题，38K个代码气味，28K个错误和57K个重构。项目分析花了200多天。在本文中，我们描述了数据检索管道以及用于分析的工具。该数据集通过CSV文件和SQLite数据库提供，以方便对数据的查询。技术债务数据集旨在为技术债务研究开辟多种机会，使研究人员能够比较常见项目的结果。
2019-08-02 cs.SE
Self-Admitted Technical Debt in LLM Software: An Empirical Comparison with ML and Non-ML Software
École de Technologie Supérieure - ÉTS Montreal（蒙特利尔高等工程技术学院）；Trent University（特伦特大学）
本文通过实证研究比较了大语言模型、机器学习和非机器学习软件中的技术债情况，发现LLM系统积累技术债的速度与ML系统相似，但保持无债时间更长，并发现了三种新的技术债类型。
2026-01-20 cs.SE
Manifesto from Dagstuhl Perspectives Workshop 24452 -- Reframing Technical Debt
本文是达格斯图尔展望研讨会24452的技术债务重定义宣言，梳理了技术债务管理的现状与不足，划分五大研究主题，提出含具体里程碑的实现路线图。
2025-05-19 cs.SE
Technical Debt and Waste in Non-Functional Requirements Documentation: An Exploratory Study
背景资料：为了充分关注非功能性需求（NFR），它们必须被文档化;否则，开发人员将不知道它们的存在。然而，NFR的文档可能会受到技术债务和浪费的影响，就像任何其他软件人工制品一样。目的：目标是探讨NFR文件中潜在的技术债务和浪费指标。方法：基于从最近的NaPiRE（消除需求工程中的痛苦）调查中获得的数据子集，我们计算了一组标准的NFR类型，当受访者还表示NFR很重要时，他们记录特定类型的NFR的频率。这使我们能够量化潜在的技术债务和浪费的发生。结果如下：根据398份调查问卷，四种NFR类型（可维护性、可靠性、可用性和性能）被认为是重要的，但超过22%的受访者没有记录。我们认为这些NFR类型的技术债务风险高于其他NFR类型。关于废弃物，15%的受访者表示他们记录了与安全相关的NFR，他们认为这并不重要。结论：有明确迹象表明，由于缺乏重要的国家森林资源报告的文件，固定的一套国家森林资源报告存在技术债务的风险。产生废物的潜在风险也存在，但程度较轻。
2019-09-27 cs.SE
"TODO: Fix the Mess Gemini Created": Towards Understanding GenAI-Induced Self-Admitted Technical Debt
Missouri University of Science and Technology（密苏里科技大学）
本文研究了GenAI在软件开发中导致的技术债务问题，提出GIST概念框架，分析开发者在使用AI生成代码时的自我承认行为及技术债务的产生原因。
2026-01-12 cs.SE
A Practical Guide to Establishing Technical Debt Management (TDM Guide for Practitioners)
本文提供了一份指导团队建立技术债务管理系统的实用指南，区分最佳实践和可选内容，旨在提供灵活性而非僵化框架。
2026-03-03 cs.SE
SoHist: A Tool for Managing Technical Debt through Retro Perspective Code Analysis
针对现有技术债务分析工具SonarQube的局限性及行业未满足需求，研究提出新型工具SoHist，通过回溯式代码分析优化技术债务评估与优先级排序，并在两个工业场景中验证其应用。
2023-04-27 cs.SE
What's behind tight deadlines? Business causes of technical debt
紧迫的截止日期背后的业务原因是什么？是什么推动了特性的优先级，将质量问题推到了次要位置？我们对71名有经验的从业人员进行了一项调查，并对以下问题的开放式答案进行了主题分析："您能否举例说明企业如何助长技术债务？与业务有关的原因分为两类：纯业务和业务/IT差距，它们与“紧迫的最后期限”和“功能高于质量”有关，这是技术债务最常被引用的管理原因。我们贡献了一个因果关系模型，它涉及到各种业务原因的紧迫的最后期限和优先级的质量方面的功能的行为。
2023-03-20 cs.SE
A Preliminary Model for Managing Technical Debt in an Agile Environment
UADER-FCyT（乌尔基萨大学艺术与科学学院）
提出一个集成管理敏捷环境中非自愿技术债务的初步模型，通过动态策略平衡新开发与修复，并考虑边际价值递减，经敏感性分析和蒙特卡洛模拟验证。
2026-06-05 cs.SE
Identifying and Managing Technical Debt in Database Normalization Using Machine Learning and Trade-off Analysis
技术债是一个比喻，描述了软件开发活动中为实现短期目标而采取的捷径的长期影响。在这项研究中，我们探讨了一个新的技术债务，涉及到数据库规范化的设计决策。我们认为，不规范的数据库可能会对数据质量、性能下降和可维护性成本产生长期影响，就像债务积累利息一样。相反，传统的数据库方法会建议对弱规范化表进行规范化，就大型软件系统所需的工作量和专业知识而言，这可能是一个昂贵的过程。研究表明，第四范式通常被认为是数据库设计中的理想范式，因此，低于第四范式的表可能会产生数据库规范化债。我们将标准化债务项称为数据库中第四范式以下的任何表。我们提出了一个识别正常化债务的框架。我们的框架利用关联规则挖掘来发现表中属性之间的函数依赖关系，这将有助于确定该表的当前范式并识别债务表。为了管理这样的债务，我们提出了一个权衡分析方法，优先表是正常化的候选人。在返工成本和债务对系统质量的影响之间进行权衡，作为隐喻性的利益。为了评估我们的方法，我们使用了微软的案例研究，AdventureWorks。实验结果表明，该方法可以减少规范化的成本和工作量，同时改善数据库设计。
2018-01-25 cs.SE
An Exploratory Study on the Occurrence of Self-Admitted Technical Debt in Android Apps
技术债描述了开发人员编写的代码不符合项目里程碑的情况。然而，这种债务积累往往会导致未来的开发人员努力解决这些质量问题。为了更好地管理这种债务，开发人员可以将他们的次优代码记录为代码中的注释（即，自我承认的技术债务或SATD）。虽然先前的研究已经调查了SATD的发生和特征，但本研究主要集中在非移动系统上。随着数百万的移动应用程序（应用程序）在多种类型可供最终用户，有一个缺乏研究的次优代码开发人员故意实现在移动应用程序。在这项研究中，我们研究了15，614个开源Android应用程序中SATD的发生和特征。我们的研究结果表明，即使这些应用程序包含SATD的发生，每个应用程序的数量（中位数为4）低于非移动系统，大多数债务被归类为代码债务。此外，我们还确定了应用程序中容易出现故意次优实现的典型元素。我们设想我们的研究结果支持研究人员和工具供应商构建工具和技术，以支持应用程序开发人员进行应用程序维护。
2023-03-03 cs.SE
Towards Measuring the Impact of Technical Debt on Lead Time: An Industrial Case Study
本研究通过工业案例探讨技术债务对Jira问题解决交付周期的影响，发现其影响在不同组件中呈混合表现，仅能解释5%至41%的周期差异，需进一步调查其他混杂变量。
2024-06-03 cs.SE
Detection of Technical Debt in Java Source Code
本研究通过分析974个Java项目的注释及源代码，构建了首个结合代码注释的TD数据集，并证明包含分类代码能显著提升各类技术债务预测的准确率，为后续研究提供了数据集与基线分类器。
2025-08-09 cs.SE
Technical Debt in Data-Intensive Software Systems
当今数据的数量、种类以及生成和处理速度的不断增加给数据密集型软件系统（DISS）的开发提出了各种新的挑战。与开发其他类型的软件系统一样，开发DISS通常是在严重的压力和严格的时间表下完成的。因此，DISS的开发人员经常不得不做出技术妥协，以满足业务需求。本立场文件提出了一个概念模型，概述了技术债务（TD）可以出现和扩散在这样的数据为中心的系统中，通过将DISS分为三个部分（软件系统，数据存储系统和数据）。此外，本文还通过两个实例说明了在以关系数据库为中心的软件系统中数据库模式气味作为TD项的扩散。
2019-05-31 cs.SE
Towards the Definition of Enterprise Architecture Debts
在软件开发行业中，技术债务被认为是一个关键问题，因为它会导致软件开发成本增加、产品质量下降、可维护性下降以及软件开发长期成功的进展缓慢。然而，尽管在软件工程的技术债务管理的研究贡献巨大，技术债务的想法未能提供一个整体的考虑，包括IT和业务方面。此外，由于资源的不确定性和不可用性，实现企业架构（EA）项目可能并不总是成功的。因此，我们将EA实现失败的后果与一个新的隐喻--企业架构债务（EA债务）联系起来。我们预计EA债务的积累将对EA质量产生负面影响，并使业务面临风险。
2019-06-28 cs.SE
FIXME: Synchronize with Database An Empirical Study of Data Access Self-Admitted Technical Debt
开发人员有时会因为紧张的发布时间表的压力而选择设计和实现的捷径。然而，快捷方式引入了技术债务，随着软件的发展而增加。债务需要尽快偿还，以尽量减少其对软件开发和软件质量的影响。有时，开发人员在评论和提交消息中承认技术债务。这种债务被称为自我承认的技术债务（SATD）。在数据密集型系统中，数据操作是一个关键功能，在数据访问逻辑中存在SATD可能会严重损害性能和可维护性。了解SATD在软件系统中的组成和分布及其演变可以为有效管理技术债务提供见解。我们提出了一个大规模的实证研究的患病率，组成和演变的SATD在数据密集型系统。我们分析了83个依赖于关系数据库的开源系统以及19个依赖于NoSQL数据库的系统。我们在从主题系统的不同快照获得的源代码注释中检测到SATD。为了了解SATD的进化动力学，我们进行了生存分析。接下来，我们对361个样本数据访问SATD进行了手动分析，调查了数据访问SATD的组成以及引入和删除它们的原因。我们确定了15个新的SATD类别，其中11个是特定于数据库访问操作。我们发现，大多数数据访问SATD是在变更历史的后期阶段而不是在开始时引入的。我们还观察到，bug修复和重构是引入数据访问SATD的主要原因。
2022-01-06 cs.SE
An Analysis of Technical Debt Management Through Resources Allocation Policies in Software Maintenance Process
本文基于系统动力学方法，在大量文献回顾和二手数据的基础上，建立了一个计算模拟模型，通过分析软件维护过程中的资源配置策略，分析了软件维护过程中的技术债务管理，以说明不同的策略如何导致不同行为的出现。大多数将系统动力学应用于软件项目研究的工作，都集中在其生存周期的初始阶段，而对于运行和维护阶段的长期行为则留下了空白。结果表明，过度关注完善的维护活动可能比进行定期预防性维护以减少所产生的技术债务成本更高，最终部署的功能更少，积压更高，生产力更低，可维护性更低，技术原理更高。
2016-09-22 cs.SE
Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems
自我承认的技术债务（SATD）是技术债务（TD）的一种特殊情况，开发人员明确承认他们的次优实现决策。以前的研究通过在源代码注释中搜索特定的TD相关术语来挖掘SATD。相比之下，在本文中，我们认为开发人员可以通过其他方式承认技术债务，例如，通过在跟踪系统中创建问题并将其标记为涉及TD。我们将这种类型的SATD称为基于问题的SATD或SATD-I。我们研究了从五个开源项目中收集的286个SATD-I实例的样本，包括Microsoft Visual Studio和GitLab Community Edition。我们发现，只有29%的研究SATD-I实例可以跟踪到源代码注释。我们还表明，SATD-I问题需要更多的时间来关闭，相比其他问题，虽然他们并不更复杂的代码流失。此外，在所研究的问题中，45%的TD是在早期引入的，近60%的TD是指设计缺陷。最后，我们报告说，大多数开发人员支付SATD-I，以减少其成本或利益（66%）。我们的研究结果表明，有空间设计新的工具，以支持技术债务管理，特别是工具，鼓励开发人员创建和标签问题包含TD的关注。
2020-03-20 cs.SE
