An Exploratory Study of the Relationship between SATD and Other Software Development Activities
本文通过分析77个开源Java项目，研究SATD的添加与移除同重构、缺陷修复等开发活动的共现关系，发现SATD移除与重构在95%的项目中同时发生，并识别出三类与SATD关联更频繁的重构操作。
2024-04-02 cs.SE
Measuring the Impact of Technical Debt on Development Effort in Software Projects
本研究针对软件项目中技术债务影响开发效率的问题，结合开源与企业项目数据实证分析技术债务带来的额外工作量及推迟偿还的长期影响，提出技术债务管理框架以助力相关人员管控其对生产力和成本的影响。
2025-02-22 cs.SE
Towards the Assisted Decomposition of Large-Active Files
紧密耦合和相互依赖的系统要求开发人员仔细协调他们的更改，甚至在修改应该相互独立的子系统时也是如此，从而抑制了生产力。糟糕的体系结构决策经常导致出现大型的、易更改的源文件，这些文件是复杂的技术债务的中心。这种技术债务通过协调成本和错误倾向很快引起了人们的兴趣。在本文中，我们提出了一种新的方法来分解这些“大型活动”文件，以偿还关键的技术债务。我们将我们的方法打包为一个重构推荐系统。每个建议都是通过分析文件之间的共同更改和相互依赖的模式来确定的。每个建议对应于大型活动文件相对于系统其余部分的责任。通过将推荐的功能从大型活动文件移动到较小的文件中，开发人员可以减少负债累累的文件的影响，并阐明其基本职责。与以前的工作相比，这种方法的一个关键优势是我们可以更好地集中精力;我们避免了花费开发人员的精力来重构那些只是表面上有问题的代码。我们通过将修订历史纳入确定和排名建议来实现这一点。每个建议都对应于一些易于更改的职责。我们提出了一些这种方法在行动中的例子，并概述了我们未来的计划。
2023-02-17 cs.SE
Preventing Technical Debt by Technical Debt Aware Project Management
技术债（TD）是软件内部质量问题。它们往往是由于项目期限紧迫而签订的，例如快速修复和变通办法，并且可能使未来的更改成本更高或不可能。TD预防应该比TD偿还更重要，因为后续的重构和再工程通常比从一开始就构建正确的解决方案更昂贵。虽然有许多关于TD还款的工作，但对TD预防的解决方案研究不足。本文评估了一个框架，侧重于TD预防和TD还款。它是由一家出版社的IT部门开发并应用的。该框架的独特贡献是将TD管理纳入项目管理。进行了评估的研究，根据门票统计和结构化调查的参与者从观察IT单位和比较单位。评价表明，采用这一框架提高了人们对缩小贸易逆差的认识。这带来的好处包括更理性的讨论和决策、TD预防和TD票据的及时偿还。
2021-04-09 cs.SE
Technical Debt Prioritization: State of the Art. A Systematic Literature Review
背景软件公司需要管理和重构技术债务问题。因此，有必要了解重构技术债务是否以及何时应该优先于开发功能或修复错误。Objective.本研究的目的是调查现有的知识体系在软件工程，以了解技术债务优先级的方法已被提出在研究和工业。法我们对截至2018年发表的384篇独特论文进行了系统性文献综述，遵循软件工程中应用的综合方法。我们纳入了38项主要研究。结果已经提出了不同的方法来确定技术债务的优先次序，所有这些方法都有不同的目标和不同的标准。拟议的措施只捕捉了在实践中用于定性地确定技术债务优先次序的众多因素中的一小部分。我们报告了这些因素的影响图。然而，缺乏一套经验性的、经过验证的工具。结论我们注意到，技术性的债务优先级研究是初步的，在什么是重要因素以及如何衡量这些因素方面没有达成共识。因此，我们不能认为目前的研究结论，在本文中，我们概述了必要的未来调查的不同方向。
2020-01-30 cs.SE
Behind the Scenes: On the Relationship Between Developer Experience and Refactoring
重构被广泛认为是通过实施最佳设计实践或处理设计缺陷来管理技术债务和维护健康软件项目的有效技术之一。以前的重构调查表明，代码重构活动主要是由开发人员执行的，他们对系统的设计有足够的了解，并在开发团队中担任领导角色。然而，这些调查主要限于具体的项目和公司。在本文中，我们通过分析800个开源项目来探索以前结果的普遍性。我们挖掘他们的重构活动，并确定他们相应的贡献者。然后，我们将经验得分与每个贡献者相关联，以测试与得分较高的开发人员是否倾向于1）执行更多的重构操作2）在重构背后表现出不同的动机3）更好地记录他们的重构活动有关的各种假设。我们发现：（1）尽管重构并不局限于一部分开发人员，但那些贡献分数较高的开发人员往往比其他人执行更多的重构;（2）虽然重构背后的经验和动机之间没有相关性，但顶级贡献的开发人员被发现执行更广泛的重构操作，而不管其复杂性如何;以及（3）贡献最大的开发人员倾向于较少地记录他们的重构活动。我们对三个随机抽样项目的定性分析表明，负责大多数重构活动的开发人员通常在他们的开发团队中处于高级位置，这表明他们对系统设计的广泛了解。
2021-09-23 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
Does Migrate a Monolithic System to Microservices Decrease the Technical Debt?
背景从单体系统到微服务的迁移涉及系统的深度重构。因此，迁移通常会产生很大的经济影响，公司往往会在此过程中推迟几项活动，主要是为了加快迁移本身，但也是因为需要发布新功能。Objective.我们监测了一家中小型企业的技术债务，同时将一个遗留的单片系统迁移到微服务生态系统，以分析迁移到微服务之前和之后代码技术债务的变化。法我们进行了一个案例研究，分析了一个大项目（28万行代码）四年多的历史，其中两个团队从整体系统中提取了五个业务流程作为微服务，首先使用SonarQube分析技术债务，然后与开发人员进行定性研究，以了解系统的感知质量和最终推迟活动的动机。结果.从长远来看，微服务的发展有助于减少技术债务。尽管由于新微服务的发展，技术债务最初出现了峰值，但在相对较短的时间内，技术债务的增长速度往往比单片系统慢。
2020-07-04 cs.SE
How Do I Refactor This? An Empirical Study on Refactoring Trends and Topics in Stack Overflow
作为软件维护和演化的重要组成部分，重构由开发人员执行，无论技术或领域如何，以提高系统的内部质量，并减少其技术债务。然而，选择合适的重构策略并不总是那么简单，这导致开发人员寻求帮助。虽然重构的研究已经很成熟，有几项研究在检测重构机会和建议适当的代码更改之间进行了改变，但对它们在实践中的采用知之甚少。分析开发人员的认知对于更好地理解开发人员认为代码中存在的问题以及他们如何处理这些问题至关重要。此外，需要通过提取更适合开发人员实际情况的常见重构意图，来弥合研究重构与实际应用之间的差距。在这项研究中，我们通过一系列定量和定性的实验，分析重构讨论堆栈溢出。我们的研究结果表明，堆栈溢出是由一组不同的开发人员用于重构援助的各种技术。我们的观察显示了开发人员在重构时通常需要帮助的五个方面--代码优化、工具和IDE、体系结构和设计模式、单元测试和数据库。我们设想我们的研究结果更好地桥接重构的传统（或学术）方面与其现实世界的适用性之间的支持，包括更好的工具支持。
2021-10-23 cs.SE
Can Clean New Code reduce Technical Debt Density?
虽然随着软件系统的发展，技术债务的绝对数量会增加，但在某些情况下，技术债务的密度（技术债务除以代码行）会降低。这可以通过重构的应用或开发具有有限技术债务的新工件来解释。本文通过考察新法规中的技术债务数额与技术债务在制度中的演变之间的关系，探讨了第二种解释。为此，我们将新代码与现有代码的技术债务密度进行比较，并调查三种主要类型的代码更改（添加，删除和修改）中的哪一种主要负责技术债务密度的演变。此外，我们研究是否有代码质量的做法和新代码的“清洁”之间的关系。为了获得所需的数据，我们对Apache软件基金会的27个开源软件项目进行了大规模的案例研究，分析了66，661个类和56，890个提交。结果表明，编写“干净”（或至少“干净”）的新代码可以是降低技术债务密度的有效策略，从而防止软件随着时间的推移而衰退。研究结果还表明，采用明确的质量改进政策的项目，例如通过在董事会会议上讨论代码质量，与更干净的新代码提交频率较高有关。因此，我们倡导建立监控新代码的技术债务密度的过程，以控制软件系统中技术债务的积累。
2020-10-19 cs.SE
Quantifying Technical Debt: A Systematic Mapping Study and a Conceptual Model
为了有效地管理技术债务（TD），我们需要可靠的方法来量化它。我们进行了一项系统映射研究（SMS），在该研究中，我们确定了侧重于TD不同方面的TD量化方法。一些方法基于气味的识别进行量化，一些方法量化重构的投资回报率（ROI），一些方法在软件质量方面比较软件的理想状态和当前状态，还有一些方法比较替代开发路径以减少TD。目前尚不清楚这些方法是否量化了同一件事，以及它们是否支持有关TD管理（TDM）的类似或不同决策。这就造成了无法有效比较和评价各种办法的问题。为了解决这个问题，我们开发了一个新的概念模型，技术债务量化模型（TDQM），捕捉到的重要概念，TD量化，并说明它们之间的关系。TDQM可以通过一个共同的统一表示，TDQM方法比较矩阵，允许执行有用的比较和方法之间的评估代表不同的TD量化方法。本文报告的映射研究，TDQM的发展，并应用TDQM比较和评估TD量化方法。
2023-03-12 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
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
Automating Source Code Refactoring in the Classroom
本文探讨了在课堂中使用 Eclipse 插件 JDeodorant 进行反模式检测与代码重构的教学实践，对 171 名学生的实验结果表明该工具有效提升了学生对重构概念的认知与学习满意度。
2023-11-05 cs.CY cs.SE
Do AI Agents Really Improve Code Readability?
National Institute of Technology, Nara College（奈良工业高等专门学校）；Nara Institute of Science and Technology（奈良先端科学技术大学院大学）
研究探讨AI代理重构对代码可读性的影响，通过分析403个提交发现，AI主要改进逻辑复杂度和文档，但导致传统质量指标下降。
2026-03-14 cs.SE
CodeTaste: Can LLMs Generate Human-Level Code Refactorings?
University of California, Berkeley（加州大学伯克利分校）；ETH Zurich（苏黎世联邦理工学院）
研究LLM代理在代码重构中的能力，通过CodeTaste基准测试发现，代理在详细指定重构时表现良好，但难以自主发现人类选择的重构，提出“先提议后实现”分解可改善对齐。
2026-06-08 cs.AI cs.LG cs.SE
Artificial Intelligence for Technical Debt Management in Software Development
LUT University（拉普兰塔理工大学）
本文通过文献综述分析15篇论文，探讨AI技术在软件开发中管理技术债务的有效性，指出AI有潜力改善管理，但面临数据质量与伦理挑战。
2023-06-16 cs.AI cs.SE
Analyzing the concept of technical debt in the context of agile software development: A systematic literature review
本研究通过系统性文献综述，从346项研究中筛选38项，分析敏捷软件开发中技术债务的研究现状、成因、后果及管理策略，梳理出5个研究方向、8类成因、5类后果和12种管理策略，为该领域提供结构化综合与后续研究方向。
2024-01-26 cs.SE
Microservices, Continuous Architecture, and Technical Debt Interest: An Empirical Study
持续架构（CA）是一种支持公司缩短交付间隔时间的方法。迁移到微服务是公司采用持续架构流程时最常见的情况之一[4]。公司通常采用初始迁移策略，利用简化的微服务模式从整体系统中提取一些组件作为微服务[5][4]。例如，公司通常直接将微服务连接到传统的单片系统，并且在开始时不采用任何消息总线。当系统开始变得越来越复杂时，他们通常会考虑不同的架构模式，重新构建系统。一些公司引入API网关模式来简化不同服务的管理和负载均衡，而另一些公司也考虑轻量级消息总线[4][5][6]。所有这些架构变化都需要对系统进行深度重构，从而增加了引入新故障的风险。在本文中，我们报告了正在进行的工作的初步结果，我们监测了采用CA方法的中小企业（SME =中小型企业）的TD，同时将传统的单片系统迁移到微服务生态系统。据我们所知，目前还没有关于推迟活动对TD的影响的研究，特别是在CA和微服务的背景下。这项工作将帮助公司了解TD如何随着时间的推移而增长和变化，同时为未来研究TD在持续架构过程中的兴趣分析开辟新的途径。
2018-10-25 cs.SE
Potential Technical Debt and Its Resolution in Code Reviews: An Exploratory Study of the OpenStack and Qt Communities
技术债务（TD）是指开发人员为了实现短期目标而牺牲长期代码质量的情况，这可能对软件系统的质量产生负面影响。在代码评审的上下文中，这种次优实现有机会在代码合并之前的评审过程中及时解决。因此，我们可以将其视为潜在技术债务（PTD），因为当PTD被注入软件系统而没有得到解决时，它将演变为TD。到目前为止，对PTD在代码评审中被识别的程度知之甚少。为此，我们进行了一项探索性研究，试图了解代码审查中PTD的性质，并在识别后追踪PTD的解决方案。我们从OpenStack的Nova项目和Qt的Qt Base项目中随机收集了2,030条评论。然后，我们手动检查这些审查意见，并获得163个PTD相关的审查意见，以供进一步分析。我们的研究结果表明：（1）PTD可以在代码评审中识别，但并不普遍。(2)设计、缺陷、文档、需求、测试和代码PTD在代码评审中确定，其中代码和文档PTD占主导地位。(3)在代码评审中发现的PTD中，有81.0%已被开发人员解决，78.0%已解决的TD在一周内被开发人员解决。(4)代码重构是开发人员用来解决代码评审中识别的PTD的主要实践。我们的研究结果表明：（1）基于审查的PTD检测被视为开发中值得信赖的机制之一，（2）当注入软件系统时，仍有相当大比例的PTD（19.0%）仍未解决。实践者和研究者应该建立有效的策略来管理和解决发展中的PTD。
2022-09-24 cs.SE
SmellCC: A Tool for Automated Code Smells Remediation
Zhejiang University（浙江大学）
SmellCC是一款Visual Studio Code扩展，结合SonarQube与LLM流水线，采用思维链和少样本学习，可一键修复Python前10种常见代码异味，清洁率96.8%、准确率91.3%，能提升软件可维护性。
2026-08-11 cs.SE
Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution
University of Verona（维罗纳大学）；Singapore Management University（新加坡管理大学）；Technology Innovation Institute（技术创新研究所）；Harbin Institute of Technology（哈尔滨工业大学）
研究通过共进化视角分析Dockerfile中的SATD，发现约27%的承认事件和40%的偿还事件与非Dockerfile文件相关，且耦合源是子类型特定的，同时外部依赖问题是最常见的承认触发原因，而架构重构是偿还SATD的主要前提。
2026-05-20 cs.SE
Predicting Community Smells' Occurrence on Individual Developers by Sentiments
社区气味出现在次优的软件开发社区结构中，导致不可预见的额外项目成本，例如，生产力下降，技术债务增加。以前的研究分析和预测社区气味的粒度社区亚组使用社会技术因素。然而，重构这种气味需要开发人员单独努力。要消除这些障碍，必须根据其主题和工作状态，为每个开发人员制定相应的支持措施。最近的研究表明，开发人员的个性可能会影响社区气味的变化，他们的情绪可能会影响生产力。因此，情绪可以被评估来预测社区气味在他们身上的发生。为此，本文构建了一个面向开发人员的感知社区气味预测模型，考虑了组织筒仓，孤狼和瓶颈等3种气味。此外，它还预测开发商是否在受到任何气味影响后离开社区。所提出的模型实现了跨项目和项目内的预测F-测量范围从76%到93%。研究还发现，与活跃度指标相比，6个情感特征具有更强的预测能力。祈使语和指示性表达、礼貌和几种情绪是最有力的预测因素。最后，我们统计测试的平均值和分布的情感特征。根据我们的研究结果，我们建议开发人员应该以直接和礼貌的方式进行沟通。
2021-03-12 cs.SE
