Technical debt and agile software development practices and processes: An industry practitioner survey
内容：现代软件开发通常是在动态的、资源稀缺的环境中进行的，这些环境容易积累技术债务。虽然这种普遍现象是公认的，但仍然未知的是技术债务如何具体体现在软件过程中并影响软件过程，以及所采用的软件开发技术如何适应或减轻这种债务的存在。目的：我们试图借鉴从业者的见解和经验，以便对敏捷方法的使用对技术债务管理的影响进行分类。我们探讨了从业者对技术债务的知识广度;技术债务如何在软件过程中表现出来;以及常见的敏捷软件开发实践和过程对技术债务的影响。在这样做的过程中，我们解决了技术债务知识的研究差距，并提供新颖的和可操作的管理建议。方法：我们设计，测试和执行了一个多国调查问卷，以解决我们的目标，从巴西，芬兰和新西兰的从业者收到184个答复。结果如下：我们的研究结果表明：1）实践者意识到技术债务，尽管这个概念还没有得到充分利用; 2）技术债务通常存在于遗留系统中，但是，技术债务的具体实例很难概念化，这使得管理成为问题; 3）质疑敏捷实践和过程有助于减少技术债务;特别是，验证和维护已实现工件的结构和清晰度的技术。结论：技术债务情况往往具有共同的特点，这一事实意味着对其管理采取系统的办法是可行的。然而，尽管一些灵活做法对技术债务管理产生了积极影响，但利益攸关方之间的利益冲突仍然是一个令人关切的问题。（节录）
2021-04-30 cs.SE
Measuring the Impact of Technical Debt on Development Effort in Software Projects
本研究针对软件项目中技术债务影响开发效率的问题，结合开源与企业项目数据实证分析技术债务带来的额外工作量及推迟偿还的长期影响，提出技术债务管理框架以助力相关人员管控其对生产力和成本的影响。
2025-02-22 cs.SE
The use of incentives to promote Technical Debt management
在开发软件时，保持技术债务的水平是至关重要的，因为从几项研究中可以很好地确定技术债务可以，例如，降低了开发效率，降低了开发人员的士气，并损害了软件的整体质量。然而，即使在今天的软件开发行业的研究人员和从业人员都非常熟悉的概念，技术债务及其相关的负面影响，一直没有实证研究，特别是软件管理人员如何积极沟通和管理的需要，以保持尽可能低的技术债务水平。
2021-01-05 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
An insight into the technical debt-fix trade off in software backporting
University of Saskatchewan（萨斯喀彻温大学）
本研究分析三个软件生态系统87个仓库的向后移植数据，发现约4.3%的向后移植引入技术债务，不同生态系统债务分布阶段及开发者因素存在差异，揭示了稳定版本向后移植中技术债务产生的规律。
2025-11-12 cs.SE
Towards the Definition of Enterprise Architecture Debts
在软件开发行业中，技术债务被认为是一个关键问题，因为它会导致软件开发成本增加、产品质量下降、可维护性下降以及软件开发长期成功的进展缓慢。然而，尽管在软件工程的技术债务管理的研究贡献巨大，技术债务的想法未能提供一个整体的考虑，包括IT和业务方面。此外，由于资源的不确定性和不可用性，实现企业架构（EA）项目可能并不总是成功的。因此，我们将EA实现失败的后果与一个新的隐喻--企业架构债务（EA债务）联系起来。我们预计EA债务的积累将对EA质量产生负面影响，并使业务面临风险。
2019-06-28 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
Long-Term Evaluation of Technical Debt in Open-Source Software
现有的软件工具能够在选择的粒度级别上表征和测量技术债务的数量。本文旨在研究开源软件中技术债的演变和特征。我们进行了一项纵向研究，涵盖了几个复杂应用程序的整个开发历史。我们研究了技术债务是如何引入软件的，以及确定开发人员如何处理其长期积累。我们使用三个复杂的开源Java应用程序进行了评估。使用SonarQube分析了所有110个已发布的版本，涵盖了每个应用程序超过10年的开发历史。我们研究了技术债务的数量、组成和历史在开发过程中的变化，比较了我们在研究应用中的结果，并提出了我们最重要的发现。对于每个应用程序，我们都确定了关键版本，在此期间，大量的技术债务被添加，删除或两者兼而有之。与开发期间通常发生的代码行或类计数增加相比，这具有更大的影响。在每个版本中，我们发现文件代码行和技术债务之间存在高度相关性。我们观察到，帕累托原则是满意的研究应用程序，因为20%的问题类型产生了约80%的总技术债务。早期的应用程序版本显示，现有技术债务的金额波动较大。应用程序的大小似乎是一个不可靠的预测技术债务的数量。大多数债务是作为扩展其功能集的里程碑版本的一部分引入应用程序的。我们还发现，技术债务问题在源代码中持续存在很长一段时间，并且它们的删除似乎没有根据类型或严重程度进行优先级排序。
2020-07-27 cs.SE
UX Debt: Developers Borrow While Users Pay
本文提出UX债务概念，将关注点从代码转向用户，归纳并通过专家调查验证三类UX债务，为团队缓解面向用户应用中的UX债务提供建议。
2024-01-28 cs.SE
Technical Debt Management: The Road Ahead for Successful Software Delivery
本文调研了产业界与研究界的技术债务管理现状，梳理实践缺口与研究不足，提出未来五年技术债务管理的发展愿景，为软件系统的长期健康交付提供方向指引。
2024-03-11 cs.SE
Technical Debt in Data-Intensive Software Systems
当今数据的数量、种类以及生成和处理速度的不断增加给数据密集型软件系统（DISS）的开发提出了各种新的挑战。与开发其他类型的软件系统一样，开发DISS通常是在严重的压力和严格的时间表下完成的。因此，DISS的开发人员经常不得不做出技术妥协，以满足业务需求。本立场文件提出了一个概念模型，概述了技术债务（TD）可以出现和扩散在这样的数据为中心的系统中，通过将DISS分为三个部分（软件系统，数据存储系统和数据）。此外，本文还通过两个实例说明了在以关系数据库为中心的软件系统中数据库模式气味作为TD项的扩散。
2019-05-31 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
Towards Quantifying Requirements Technical Debt for Software Requirements concerning Veracity: A Perspective and Research Roadmap
本文提出将需求技术债务（RTD）的量化视角应用于软件需求真实性，通过提出“真实性债务”概念和研究路线图，支持对涉及真相、信任与可证明性的需求进行债务管理。
2024-06-29 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
Can Clean New Code reduce Technical Debt Density?
虽然随着软件系统的发展，技术债务的绝对数量会增加，但在某些情况下，技术债务的密度（技术债务除以代码行）会降低。这可以通过重构的应用或开发具有有限技术债务的新工件来解释。本文通过考察新法规中的技术债务数额与技术债务在制度中的演变之间的关系，探讨了第二种解释。为此，我们将新代码与现有代码的技术债务密度进行比较，并调查三种主要类型的代码更改（添加，删除和修改）中的哪一种主要负责技术债务密度的演变。此外，我们研究是否有代码质量的做法和新代码的“清洁”之间的关系。为了获得所需的数据，我们对Apache软件基金会的27个开源软件项目进行了大规模的案例研究，分析了66，661个类和56，890个提交。结果表明，编写“干净”（或至少“干净”）的新代码可以是降低技术债务密度的有效策略，从而防止软件随着时间的推移而衰退。研究结果还表明，采用明确的质量改进政策的项目，例如通过在董事会会议上讨论代码质量，与更干净的新代码提交频率较高有关。因此，我们倡导建立监控新代码的技术债务密度的过程，以控制软件系统中技术债务的积累。
2020-10-19 cs.SE
Impostor Phenomenon as Human Debt: A Challenge to the Future of Software Engineering
Pontifical Catholic University of Rio de Janeiro（里约热内卢天主教大学）；University of Bari（巴里大学）；Eindhoven University of Technology（埃因霍温理工大学）
本文将冒名现象视为人类债务，探讨其对软件工程未来的影响，并提出通过文化重构和盟友关系来缓解这一问题。
2026-02-14 cs.SE
Non Technical Debt in Agile Software Development
本研究基于NODLA项目的调查、访谈与统计分析，识别大规模敏捷开发中四类非技术债务的驱动因素与影响，并提出减少债务、恢复敏捷性的循证策略。
2025-09-01 cs.SE
DebtViz: A Tool for Identifying, Measuring, Visualizing, and Monitoring Self-Admitted Technical Debt
针对自承认技术债务（SATD）综合管理工具匮乏的问题，本文提出DebtViz工具，采用卷积神经网络检测、反卷积提取关键词，具备检测分类、可视化监控等功能，可提升SATD管理效率并支持知情决策，适用于多种开发环境。
2023-08-25 cs.SE
Estimation and Prediction of technical debt: a proposal
技术债务是一个隐喻，用来表达这样一种想法，即在设计和构建软件时，以“快速而肮脏”的方式做事会导致越来越多的延迟未来费用。与金融债务类似，技术债务要求以额外发展努力的形式支付利息，如果没有做出快速和肮脏的设计选择，这种额外发展努力本可以避免。技术债适用于软件开发的所有方面，从最初的需求分析到部署和软件演化。从科学和工业的角度来看，技术债务正变得非常普遍。特别是，近年来相关论文的数量有所增加。相关工具的数量以及在行业中的采用也在增加，特别是因为技术债务非常昂贵，因此需要管理。然而，估计技术债务的技术是不充分的，因为它们主要集中在需求，代码和测试上，而忽略了关键的工件，如软件架构和软件使用的技术。此外，尽管其高度相关性，技术债务预测是技术债务的最少探索的方面之一。为了解决这些缺点，我必须进行研究：1）改进现有技术以正确估计技术债务; 2）确定使用预测技术来预测并避免技术债务的程度可以帮助公司节省资金并避免未来几年的潜在破产。拟议中的研究可以通过帮助公司节省数百万美元来产生重要的经济影响。它可以产生重大的科学影响，导致关键的发现，将通过专利，著名的科学期刊和会议传播。
2019-03-30 cs.SE
Multi-Artifact Analysis of Self-Admitted Technical Debt in Scientific Software
Boise State University（博伊西州立大学）；Oak Ridge National Laboratory（橡树岭国家实验室）
本研究通过多工件分析识别科学软件中的科学债务，发现传统SATD分类不足，需专门方法进行检测与管理。
2026-01-15 cs.SE
An Analysis of Technical Debt Management Through Resources Allocation Policies in Software Maintenance Process
本文基于系统动力学方法，在大量文献回顾和二手数据的基础上，建立了一个计算模拟模型，通过分析软件维护过程中的资源配置策略，分析了软件维护过程中的技术债务管理，以说明不同的策略如何导致不同行为的出现。大多数将系统动力学应用于软件项目研究的工作，都集中在其生存周期的初始阶段，而对于运行和维护阶段的长期行为则留下了空白。结果表明，过度关注完善的维护活动可能比进行定期预防性维护以减少所产生的技术债务成本更高，最终部署的功能更少，积压更高，生产力更低，可维护性更低，技术原理更高。
2016-09-22 cs.SE
Temporal Discounting in Technical Debt: How do Software Practitioners Discount the Future?
技术债务管理决策总是意味着在不同时间点的结果之间进行权衡。在这种跨期选择中，远距离结果的价值往往低于近距离结果，这种现象被称为时间折扣。技术债务研究主要是开发软件工程师应该如何做出这样的决定的规定性方法。很少有人研究过它们是如何制造的。这就留下了关于软件从业者如何做决策的核心问题。本文研究了软件从业者如何贴现不确定的未来结果，以及他们是否表现出时间贴现。我们采用跨期选择，一个活跃的研究领域的实验方法。我们对来自两家公司的33名开发人员进行了在线问卷调查，在问卷中，我们提出了在开发功能和对架构进行长期投资之间的选择。结果表明，广泛的时间折扣与个人行为的显着差异。研究结果与消费者行为中的类似研究一致，并提出了一些关于软件工程中影响时间折扣的因果因素的问题。作为第一个跨期选择在SE的实证研究，本文建立了一个实证基础，了解软件开发人员如何处理跨期选择，并提供了未来的研究蓝图。
2019-04-02 cs.SE
Technical Debts and Faults in Open-source Quantum Software Systems: An Empirical Study
量子计算是一个快速发展的领域，吸引了研究人员和软件开发人员的兴趣。在其众多开源工具的支持下，开发人员现在可以构建，测试或运行他们的量子算法。虽然传统软件系统的维护实践已经得到了广泛的研究，但量子软件的维护仍然是一个新的研究领域，但它是确保整个量子计算系统质量的关键部分。在这项工作中，我们着手研究量子软件中技术债务的分布和演变及其与故障发生的关系。了解这些问题可以指导未来的量子开发，并为量子软件开发人员和研究人员应该更加关注的关键领域提供维护建议。在本文中，我们实证研究了从GitHub中选择的118个开源量子项目。这些项目分为10类。我们发现，所研究的量子软件遭受的问题的代码约定违反，错误处理和代码设计。我们还观察到量子软件中的代码设计、冗余码或代码约定与故障发生之间存在统计学显著相关性。
2022-06-01 cs.SE
Exploring Scientific Debt: Harnessing AI for SATD Identification in Scientific Software
Boise State University（博伊西州立大学）；University of Victoria（维多利亚大学）；University of Tennessee（田纳西大学）；University of Toronto（多伦多大学）
本研究利用AI识别科学软件中的SATD，发现其比通用软件具有更高的债务水平，并揭示了管理SATD对科学发现的重要性。
2025-11-21 cs.SE
Exploring the Advances in Using Machine Learning to Identify Technical Debt and Self-Admitted Technical Debt
Boise State University（博伊西州立大学）
本研究探讨了利用机器学习识别技术债务和自认技术债务的现状，发现BERT模型在检测效果上表现最佳。
2024-09-06 cs.SE
Systematic literature review on forecasting and prediction of technical debt evolution
本文通过系统性综述646篇论文并分析14项主要研究，梳理技术债务演化预测方法，发现随机森林与时间卷积网络表现较优但仅覆盖代码和架构债务。
2024-06-17 cs.SE
Technical Debt Prioritization: State of the Art. A Systematic Literature Review
背景软件公司需要管理和重构技术债务问题。因此，有必要了解重构技术债务是否以及何时应该优先于开发功能或修复错误。Objective.本研究的目的是调查现有的知识体系在软件工程，以了解技术债务优先级的方法已被提出在研究和工业。法我们对截至2018年发表的384篇独特论文进行了系统性文献综述，遵循软件工程中应用的综合方法。我们纳入了38项主要研究。结果已经提出了不同的方法来确定技术债务的优先次序，所有这些方法都有不同的目标和不同的标准。拟议的措施只捕捉了在实践中用于定性地确定技术债务优先次序的众多因素中的一小部分。我们报告了这些因素的影响图。然而，缺乏一套经验性的、经过验证的工具。结论我们注意到，技术性的债务优先级研究是初步的，在什么是重要因素以及如何衡量这些因素方面没有达成共识。因此，我们不能认为目前的研究结论，在本文中，我们概述了必要的未来调查的不同方向。
2020-01-30 cs.SE
Examination of tools for managing different dimensions of Technical Debt
由于市场上有许多免费增值和高级，开源和闭源软件工具可用于处理不同维度的技术债务管理的不同活动，因此为特定活动和维度确定正确的工具集可能非常耗时。新时代的云优先工具更容易上手，而传统工具在让用户知道它能提供什么之前需要相当长的时间。此外，由于许多工具只处理诸如代码和测试债务等技术债务的几个维度，因此为其他维度（如设计、架构、文档和环境债务）识别和选择正确的工具可能会很累。我们试图通过展示我们的发现来减少这个令人厌倦的过程，这些发现可以帮助那些进入“软件开发中的技术债务”领域并随后进一步进入“技术债务管理”领域的人。
2019-04-24 cs.SE
Measuring Technical Debt in AI-Based Competition Platforms
本文通过范围综述识别并分类AI竞赛平台中的技术债务类型，提出专门的可访问性债务概念，并开发问卷与管理框架以提升平台的可持续性和可维护性。
2024-08-01 cs.SE
Tracy: A Business-driven Technical Debt Prioritization Framework
技术债是软件开发中普遍存在的问题。软件开发团队必须优先考虑债务项目，并确定他们是否应该在任何时候解决债务或开发新功能。本文介绍了“特雷西”，一个框架，优先级的技术债务使用业务驱动的方法建立在业务流程之上。当前阶段的建议框架是在设计科学研究的第三阶段，这通常是分为探索，工程和评估阶段的开始。勘探和工程阶段有来自三家公司12个不同小组的49名专业人员参加。初步评估表明，所提出的框架是一致的，其结构和结果有助于业务驱动的决策技术债务优先级。
2019-07-31 cs.SE
An Empirical Study of Self-Admitted Technical Debt in Machine Learning Software
Queen's University（女王大学）
本文研究了机器学习软件中自我承认的技术债务，发现其比例高于非机器学习项目，且在开发早期出现，长期债务多由复杂代码更改引入。
2025-11-27 cs.SE
Comprehension Debt in GenAI-Assisted Software Engineering Projects
Karlstad University（卡尔斯特德大学）
研究探讨生成人工智能工具在软件工程项目中导致理解债务的机制，识别四种积累模式和一种缓解模式，强调通过验证实践和结构化回顾减少集体认知债务。
2026-04-14 cs.SE
Strategic Technical Debt: A Real Options Approach to Early-Stage Software Experimentation
Tecnológico de Monterrey（蒙特雷科技大学）
本文将早期软件实验中刻意产生的技术债务视为看涨期权，明确策略性与有毒债务的边界，构建序贯模型得出关键结论，并开展两项预注册实证检验。
2026-08-18 cs.SE
Technical Debt: Identify, Measure and Monitor
技术债务（Technical Debt）是由Ward Cunningham提出的一个术语，用来表示将一个软件置于它从最早开始就应该具有的状态所需的调整措施。通常，组织需要从短期和长期的角度支持持续快速地交付客户价值，然后不得不在软件的质量和生产力方面做出妥协。因此，一个简单的解决方案可能是在遇到债务时偿还债务，以避免可维护性成本和随后的延迟。因此，不可避免地要确定和提出技术，以便知道何时、如何偿还TD项目。本研究旨在探讨如何识别，测量和监测技术债务使用SonarQube和PMD。
2019-10-28 cs.SE
Managing Technical Debt in a Multidisciplinary Data Intensive Software Team: an Observational Case Study
本研究通过观察性案例研究，揭示多学科数据密集型团队的技术债务管理实践，识别数据组件和管道债务，并强调需新的实现模式与工具支持。
2025-06-23 cs.SE
Identification and Measurement of Technical Debt Requirements in Software Development: a Systematic Literature Review
内容：技术债需求与规范的理想值和系统的实际实现之间的距离有关，这是为了立即获得收益的战略决策的结果，或者是环境中的意外变化。为了确保软件的发展，有必要对其进行管理。识别和度量是管理过程的前两个阶段，然而，在需求工程的学术研究中，它们很少被探讨。目的：我们的目的是调查哪些证据有助于加强TD需求管理的过程，包括识别和测量。方法：我们通过手动和自动检索对2010年至2020年的7499项研究进行了系统性文献综述，其中包括61项主要研究。结果如下：我们确定了一些与技术债务需求相关的原因，帮助识别和测量的现有策略，以及支持测量阶段的指标。结论：TD需求的研究仍处于初步阶段，尤其是管理工具。然而，对人际问题没有给予足够的重视，这是在开展这些活动时遇到的困难，因此也需要进行研究。最后，提供度量来帮助度量TD是这项工作的贡献的一部分，提供了对需求上下文中的应用程序的深入了解。
2021-07-14 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
A Longitudinal Study of Identifying and Paying Down Architectural Debt
架构债是一种技术债，它源于系统的架构设计“应该”与“现状”之间的差距。我们以两种方式度量架构债：1）根据系统范围的耦合度量，以及2）根据架构缺陷的数量和严重性。在最近的工作中，已经表明架构债的数量对软件的可维护性和演化有着巨大的影响。因此，检测和减少债务有望使软件更容易改变。本文报告的纵向研究的医疗保健通信产品创建的鱿鱼安全通信公司这家初创公司正面临着典型的权衡问题，希望响应变化的请求，但要避免不断增加的努力，积累的快速和肮脏的变化最终招致。在研究的第一阶段，我们分析了“之前”系统的状态，这表明了变更请求的影响。这项初步研究激发了对建筑债务的更深入分析。分析的结果被用来激励软件系统的全面重构。研究的第三阶段是对建筑债务进行后续分析，对所取得的改进进行量化。使用这种定量的证据，通过对Squid的建筑师进行深入采访收集的定性证据，我们提出了在实践中偿还建筑债务的成本和收益的经验教训。
2018-11-30 cs.SE
Self-Admitted Technical Debt in Scientific Software: Prioritization, Sentiment, and Propagation Across Artifacts
Boise State University（博伊西州立大学）；Oak Ridge National Laboratory（橡树岭国家实验室）
研究科学软件中自我承认技术债务的优先级、情感、持久性和跨工件传播，发现注释、提交和拉取请求中的SATD优先级高于问题，负面情感增加紧迫性，但移除和解决率低于开源软件平均水平。
2026-06-29 cs.SE
AI Writes Code, Humans Pay the Debt. An Empirical Study on the Sustainability and Evolution of Agent-Generated Code
University of Southern Denmark（南丹麦大学）；University of Oulu（奥卢大学）；University of Hawaii（夏威夷大学）
本研究通过SQuaD数据集对比智能体生成代码与开发者实际提交代码，探究智能体生成代码对软件质量、技术债务及演化的影响，为LLM智能体的负责任应用提供依据。
2026-09-07 cs.SE
Artificial Intelligence for Technical Debt Management in Software Development
LUT University（拉普兰塔理工大学）
本文通过文献综述分析15篇论文，探讨AI技术在软件开发中管理技术债务的有效性，指出AI有潜力改善管理，但面临数据质量与伦理挑战。
2023-06-16 cs.AI cs.SE
An Exploratory Study on the Introduction and Removal of Different Types of Technical Debt
为了更快地完成任务，开发人员往往不得不牺牲软件的质量。这种折衷的做法导致开发人员在未来开发中的负担越来越重。技术债务这个比喻描述了这种做法。先前的研究已经说明了技术债务的负面影响，许多研究人员调查了开发人员如何处理某种类型的技术债务。然而，很少有研究关注实践中消除不同类型的技术债务。为了填补这一空白，我们使用了不同类型的自我承认的技术债务（即，SATD）在7个深度学习框架中作为例子。这是因为深度学习框架是当今最重要的软件系统之一，因为它们在影响生活的深度学习应用中的普遍使用。此外，不同的深度学习框架的开发领域是相同的，这使我们能够找到跨项目消除不同类型技术债务的共同行为。通过挖掘这些框架的文件历史，我们发现设计债是沿着开发过程中引入最多的。在技术债的去除方面，我们发现需求债被去除的最多，而设计债被去除的最快。大多数测试债、设计债和需求债都被引入它们的开发人员删除了。基于不同类型的技术债务的引入和去除，我们讨论了不同类型的技术债务的频率的演变，以描述开发人员在开发过程中所面临的未解决的次优权衡或决策。我们还讨论了不同类型的技术债务的去除模式，强调未来的研究方向，并为从业者提供建议。
2021-01-11 cs.SE
Experiences on Managing Technical Debt with Code Smells and AntiPatterns
技术债已经成为一个常见的比喻，用来比喻软件设计和实现选择的积累，这些选择寻求快速的初始收益，但从长远来看，这些选择低于标准，适得其反。然而，作为一个比喻，技术债务并没有提供如何摆脱它的可操作的建议。为了在解决问题方面达到实用的水平，需要更有针对性的机制。对此常用的方法包括识别代码气味作为代码库中可能问题的快速指示，并检测是否存在涉及设计中明显的重复问题的AntiPatterns。对于代码气味和反模式都有已知的补救措施。在论文中，我们的目标是展示如何有效地使用常见的工具和现有的代码气味和反模式知识来检测技术债务并偿还。我们提出了两个主要结果：（i）如何使用静态代码分析和手动检查的组合来检测代码库中的代码气味，从而发现AntiPatterns;以及（ii）如何使用AntiPatterns来识别、描述和修复软件中的问题。这些经验来自一家私营公司及其长期的软件产品开发工作。
2021-03-21 cs.SE
Towards identifying and minimizing customer-facing documentation debt
本研究通过分析工业软件系统的101个文档缺陷，发现信息内容类缺陷占比最高，并提出采用动态文档生成（DDG）和自动化文档测试（ADT）来最小化文档债务。
2024-02-16 cs.SE
Towards an Holistic Definition of Requirements Debt
如果没有适当的管理，技术债务被认为对软件项目的长期成功有负面影响。然而，债务隐喻如何适用于一般的需求工程，特别是需求工程活动，并没有得到很好的理解。在现有文献的基础上，我们提出了一个整体的定义，需求债务，其中包括债务的识别，形式化，和实现的需求。我们概述了未来的评估，以验证和进一步完善我们提出的定义。这种概念化是迈向需求债监控框架的第一步，以支持涉众的决策，比如何时招致并最终偿还需求债，以及以什么样的代价
2019-07-25 cs.SE
Technical Debt and Maintainability: How do tools measure it?
软件的技术状态，即，随着越来越多的软件被开发和部署，其技术债务（TD）和可维护性越来越受到关注。由于TD和可维护性既没有统一的定义，也不容易理解，也不能直接测量，从业者可能会应用现成的工具来评估TD或可维护性，他们可能依赖于报告的结果，而不正确理解它们所体现的内容。在本文中，我们：a）系统地确定11个现成的工具来测量TD或可维护性，b）对这些工具中的每一个如何测量和计算TD或可维护性进行深入的调查，以及c）比较这些工具及其特性。我们发现，当代的工具主要集中在软件的内部质量，即，源代码的质量，它们以非常不同的方式定义和测量TD或可维护性，大多数工具测量TD或可维护性是不透明的，并且不清楚为什么一个工具的测量比另一个工具更可信或更具代表性。
2022-02-27 cs.SE
Exploration of technical debt in start-ups
通过对86个初创企业案例的调查，发现测试维度技术债务最严重，团队规模与经验是主要先例，需预先监控和控制技术债务。
2023-09-21 cs.SE
Evidence is All We Need: Do Self-Admitted Technical Debts Impact Method-Level Maintenance?
本文通过分析49个开源项目中的774,051个方法，实证研究了自承认技术债务对方法级软件维护的影响，发现SATD会降低代码质量与可读性、增加缺陷和变更倾向，并长期未解决，从而强调早期识别与主动管理的必要性。
2025-02-05 cs.SE
Community Smells -- The Sources of Social Debt: A Systematic Literature Review
社会债务描述了次优软件开发过程中不可预见的项目成本（或潜在成本）的积累。社区气味是社会技术的反模式，也是影响软件团队、开发过程、结果和组织的社会债务的一个来源。目的：根据已发表的文献，提供社区气味的概述，并描述未来的研究。方法：我们进行了系统的文献综述（SLR），以确定属性，了解起源和演变，并描述社区气味的出现。这个SLR解释了社区气味对团队合作和团队绩效的影响。结果：共纳入25项研究。社会债务描述了糟糕的社会技术决策对工作环境、人员、软件产品和社会的影响。对于30个确定的社区气味，我们提供了一个描述，管理方法，组织战略和缓解效果。我们确定了五组管理方法：组织战略，框架，模型，工具和指导方针。我们描述了社区气味的11个特性。我们开发了社区气味阶段框架，以简洁地描述社区气味的起源和演变。我们描述了每个社区气味的原因和影响。我们确定并描述了社区气味的8种原因和11种影响。最后，我们提供了8个Sankey图表，这些图表提供了对社区气味对团队合作因素和团队绩效构成的威胁的见解。结论：社区气味解释了工作条件对软件开发人员的影响。文献很少，集中在少数社区气味上。因此，社区气味还需要更多的研究。这篇评论整理了关于社区气味的最新研究成果，并为未来的研究提供了动力和教育材料。
2022-09-21 cs.SE
MAT: A simple yet strong baseline for identifying self-admitted technical debt
在软件演化过程中，开发人员往往由于特定的原因而牺牲长期的代码质量来满足短期的目标，这就是所谓的技术债。自我承认的技术债务（SATD）是指那些故意引入并由代码注释注释的债务。这些技术债务降低了软件的质量，增加了后续软件维护的成本。因此，必须及时发现和解决这些债务。最近，已经提出了许多方法来识别SATD。然而，这些方法要么具有低精度，要么在实践中实现复杂。在本文中，我们提出了一个简单的无监督基线方法，模糊匹配任务注释标签（MAT），以确定SATD。MAT不需要任何训练数据来建立预测模型。相反，MAT只检查四个任务标签（即TODO、FIXME、XXX和HACK）中的任何一个是否出现在目标项目的注释中，以识别SATD。从这个意义上说，MAT是一种自然的基线方法，具有良好的可理解性，在SATD识别。为了评估MAT的有用性，我们使用了10个开源项目来进行实验。实验结果表明，MAT有一个令人惊讶的SATD识别性能相比，国家的最先进的方法。因此，我们建议，在未来的SATD识别研究中，MAT应被视为一个易于实施的基线，任何新的方法应进行比较，以证明其有用性。
2019-10-29 cs.SE
A First Look at Duplicate and Near-duplicate Self-admitted Technical Debt Comments
自我承认的技术债务（SATD）是指由开发人员故意引入并明确记录在代码注释或其他软件工件中的技术债务（例如，问题报告）来注释开发人员在软件开发过程中做出的次优决策。在这项工作中，我们首先研究了五个流行的Apache OSS项目中重复和近似重复的SATD注释的存在和特征，即，JSPWiki、Hacker、Jackrabbit、Archiva和SystemML。我们设计了一种方法来自动识别组的重复和接近重复的SATD评论，并跟踪其演变的软件系统中挖掘的提交历史的软件项目。利用所提出的方法，我们从目标项目中识别出3，520条重复和近似重复的SATD评论，这些评论属于1，141组。我们手动分析了1,505条SATD评论的内容和上下文（每个项目抽取100组），并确定它们是否注释了相同的根本原因。我们还调查了重复的SATD注释是否存在于代码克隆中，它们是否共存于同一个文件中，以及它们是否同时被引入和删除。我们的初步研究揭示了几个令人惊讶的发现，这将有助于未来的研究，旨在改善重复SATD评论的管理。例如，在常规代码克隆中，只有48.5%的具有相同根本原因的重复SATD注释组存在，并且只有33.9%的重复SATD注释对在同一提交中引入。
2022-03-30 cs.SE
Effects of Visualizing Technical Debts on a Software Maintenance Project
技术债务（TD）隐喻被广泛用于封装众多的软件质量问题。她描述了在软件产品的设计或实现阶段采取捷径的短期利益（例如，为了满足最后期限）和采取所述捷径的长期后果之间的权衡，这可能会影响软件产品的质量。为了保证软件质量，降低软件的维护和演化成本，必须对TD进行管理。然而，用于TD检测的工具通常只考虑文件的角度（类和方法）提供结果，这在项目管理中并不常见。在这项工作中，提出了一种技术来识别/可视化TD上一个新的角度：软件功能。该技术采用挖掘软件仓库（MRS）工具，以确定软件功能和后的技术债务，影响这些功能。此外，我们还提出了一种方法来支持维护任务指导TD可视化的功能级别，旨在评估其在实际软件项目的适用性。结果表明，该方法可以有效地减少现有的TD，以及避免引入新的TD。
2019-11-18 cs.HC cs.SE
Epistemological Debt: A Conceptual Framework for AI-Dependent Software Engineering
TalentGuard；Georgia Institute of Technology（佐治亚理工学院）；Purdue University（普渡大学）
本文研究AI依赖软件工程中认知退化与系统崩溃问题，提出知识债务概念，揭示过度依赖AI验证对人类认知的影响，并通过亚马逊2026年故障案例，强调需建立严谨的人工智能教育标准以维持系统韧性。
2026-10-19 cs.CY cs.SE
Tracing the Lifecycle of Architecture Technical Debt in Software Systems: A Dependency Approach
本文通过FAN-IN和FAN-OUT依赖度量实证研究架构技术债务（ATD）的生命周期，发现偿还ATD虽短期提升软件质量，但会集中依赖关系、增加架构复杂性，且ATD文件修改频率低于非ATD文件。
2025-03-07 cs.SE
