Architecture Smells vs. Concurrency Bugs: an Exploratory Study and Negative Results
本研究探索架构异味与并发缺陷的关联，通过分析5个大型软件系统的125个版本，发现某些异味可能预示特定并发问题，但两者总体不相关，需结合项目特征具体分析。
2023-03-31 cs.SE
Are Architectural Smells Independent from Code Smells? An Empirical Study
背景架构气味和代码气味是不良代码或设计的症状，它们可能导致不同的质量问题，例如错误、技术债务或维护和进化方面的困难。一些研究表明，代码气味和架构气味经常出现在同一个文件中。然而，代码气味和架构气味之间的相关性还不清楚;一些对有限项目的研究声称架构气味可以从代码气味中衍生出来，而其他研究则相反。Objective.这项工作的目标是了解架构气味是否独立于代码气味，或者可以从代码气味或其中的一个类别中派生出来。法我们进行了一个案例研究，分析了19种代码气味，6种代码气味和4种架构气味之间的相关性。结果结果表明，架构气味与代码气味相关的发生率非常低，因此不能从代码气味中获得。结论架构气味独立于代码气味，因此值得研究人员和从业人员特别关注，研究人员应该调查它们的实际危害，从业人员应该考虑是否以及何时删除它们。
2019-04-26 cs.SE
Design principles, architectural smells and refactorings for microservices: A multivocal review
敏捷服务交付等潜在好处已经促使许多公司通过微服务提供业务功能。然而，不良气味总是在拐角处，正如大量文献所证明的那样，讨论可能违反微服务设计原则的架构气味。在本文中，我们系统地回顾了关于该主题的白色和灰色文献，以确定最受认可的微服务架构气味，并讨论允许解决这些问题的架构重构。
2019-09-10 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
Large Language Models for Analyzing Enterprise Architecture Debt in Unstructured Documentation
Stockholm University（斯德哥尔摩大学）；University of Twente（特温特大学）
本文提出利用大型语言模型自动检测企业架构异味，通过案例研究验证其在非结构化文档中的有效性，展示了LLM在企业架构治理中的应用潜力。
2026-03-29 cs.LG cs.SE
Further Investigation of the Survivability of Code Technical Debt Items
背景：技术债务（TD）讨论了为满足软件开发速度需求而做出的次优决策的负面影响。代码技术债务项（TDI）是TD的原子元素，可以在代码工件中观察到。开源系统的实证结果表明，代码气味，这只是一种类型的TDI，是如何引入和“生存”在发布周期。然而，关于代码气味的生存性的结果是否适用于其他类型的代码TDI（即，缺陷和漏洞）和工业环境中。目标：通过分析Apache基金会的两个工业案例和31个开源系统进行实证研究，了解代码TDI的生存能力。方法：我们分析了SonarQube检测到的133，670个代码TDI（35，703个来自工业系统）（193，196次提交），以使用生存性模型评估其生存性。结果如下：一般来说，代码TDI往往会在开源系统中保留并停留很长时间，而在工业系统中它们会更快地被删除。超过一定阈值的代码TDI往往会保持更长的时间，这证实了以前的结果。我们的研究结果还表明，bug往往会更快地被删除，而代码气味和漏洞往往会存活更长时间。
2021-11-02 cs.SE
Examining the Relationship of Code and Architectural Smells with Software Vulnerabilities
安全性对于为商业或个人使用而开发的软件至关重要。虽然越来越多的组织意识到应用安全编码实践的重要性，但在其中许多组织中，直到发生安全故障时才知道或解决安全问题。安全失败的根本原因是易受攻击的代码。虽然度量已被用于预测软件漏洞，我们探索代码和架构气味与安全弱点之间的关系。由于气味是软件中更深层次问题的表面指标，因此确定气味与软件漏洞之间的关系可以在漏洞预测模型中发挥重要作用。目的：探讨气味与软件漏洞的关系，以识别气味。方法：我们提取了三个系统的类、方法、文件和包级别的气味：Apache Tomcat、Apache CXF和Android。然后，我们比较了它们在报告包含易受攻击代码的易受攻击类和中性类（尚未报告漏洞的非易受攻击类）中的出现情况。结果：我们发现，与非脆弱类相比，脆弱类更有可能具有某些气味。上帝类、复杂类、大类、数据类、特征嫉妒类、大脑类与软件漏洞具有统计学显着关系。我们发现架构气味和软件漏洞之间没有显著的关系。结论：我们可以得出结论，对于所有被检查的系统，在软件漏洞和一些气味之间存在统计学上显著的相关性。
2020-10-29 cs.SE
The perception of Architectural Smells in industrial practice
建筑技术债务（ATD）被认为是工业实践中最重要的技术债务类型。在这项研究中，我们采访了21名软件工程师和架构师，调查一种特定类型的ATD，即建筑气味（AS）。我们的目标是更好地理解AS现象，并支持从业者更好地管理它，研究人员提供相关支持。本研究的结果提供了见解从业者如何看待AS和他们如何介绍他们，他们经历的维护和发展的问题，并与AS的存在，以及他们采用什么样的做法和工具来管理AS。
2021-10-13 cs.SE
Architectural Archipelagos: Technical Debt in Long-Lived Software Research Platforms
本文确定了一个模型的软件演化，是普遍存在于大型，长期的学术研究工具套件（3L-ARTS）。这种模式导致了一个“群岛”的相关，但随意组织的架构“岛屿”，并内在地诱导技术债务。我们说明了群岛模型与文献中确定的两个3L-ARTS群岛的例子。
2021-04-17 cs.SE
The Influence of Cognitive Biases on Architectural Technical Debt
本研究通过半结构化访谈软件架构师，分析认知偏差如何及何时引发架构技术债务，并提出去偏技术与组织文化的防范作用。
2023-09-25 cs.SE
A Longitudinal Study of Identifying and Paying Down Architectural Debt
架构债是一种技术债，它源于系统的架构设计“应该”与“现状”之间的差距。我们以两种方式度量架构债：1）根据系统范围的耦合度量，以及2）根据架构缺陷的数量和严重性。在最近的工作中，已经表明架构债的数量对软件的可维护性和演化有着巨大的影响。因此，检测和减少债务有望使软件更容易改变。本文报告的纵向研究的医疗保健通信产品创建的鱿鱼安全通信公司这家初创公司正面临着典型的权衡问题，希望响应变化的请求，但要避免不断增加的努力，积累的快速和肮脏的变化最终招致。在研究的第一阶段，我们分析了“之前”系统的状态，这表明了变更请求的影响。这项初步研究激发了对建筑债务的更深入分析。分析的结果被用来激励软件系统的全面重构。研究的第三阶段是对建筑债务进行后续分析，对所取得的改进进行量化。使用这种定量的证据，通过对Squid的建筑师进行深入采访收集的定性证据，我们提出了在实践中偿还建筑债务的成本和收益的经验教训。
2018-11-30 cs.SE
ROSE: Transformer-Based Refactoring Recommendation for Architectural Smells
本文提出ROSE方法，利用CodeBERT和CodeT5在200余万重构实例上微调，将架构异味修复构建为三分类问题，CodeT5以96.9%准确率实现从异味检测到可执行重构推荐的衔接。
2025-07-20 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
Qualitative analysis of the relationship between design smells and software engineering challenges
本研究开发了一种Java软件设计坏味检测工具，分析了409,539行代码，精确度达81.01%-93.43%，并揭示了设计坏味与不规律团队会议、范围蔓延等软件工程挑战的关联，为设计补救提供依据。
2023-10-22 cs.CY cs.SE
On the evolution and impact of Architectural Smells -- An industrial case study
架构气味（AS）对软件系统的可维护性和可演化性有着长期的影响。大多数的研究工作都是通过挖掘开源Java系统的软件存储库来研究这个主题的，这使得很难将它们推广并应用到工业环境和其他程序设计语言中。为了解决这一研究空白，我们进行了嵌入式多案例研究，与一个大型行业合作伙伴合作，研究如何在工业嵌入式系统AS演变。我们在9个C/C++项目中检测和跟踪AS，每个项目的开发时间超过两年，每个项目的发布版本超过30个，仅最后一个版本就有超过2000万行代码。除了这些定量结果，我们还采访了12名开发人员和建筑师，他们在这些项目中工作，收集了超过六个小时的定性数据，这些数据是关于AS分析的有用性以及他们在维护和发展受AS影响的人工制品时遇到的问题。我们的定量研究结果显示了个体气味实例如何随着时间的推移而演变，它们通常在系统中存活多久，它们如何与其他气味类型的实例重叠，以及最后当它们重叠时，气味类型的引入顺序是什么。相反，我们的定性研究结果，提供了洞察力的影响，AS的长期可维护性和系统的可演化性，从我们的采访中的几个摘录的支持。实践者还提到AS分析的哪些部分实际上提供了可操作的见解，他们可以使用这些见解来计划重构活动。
2022-03-16 cs.SE
SmellBench: Evaluating LLM Agents on Architectural Code Smell Repair
University of Craiova（克劳索瓦大学）；NVIDIA（NVIDIA公司）；University Politehnica of Bucharest（布加勒斯特理工大学）
本文提出SmellBench框架，用于评估LLM代理在修复建筑代码异味方面的性能，通过专家验证发现最佳代理修复率为47.7%，但修复 aggressiveness 与代码库质量呈负相关。
2026-05-12 cs.CL cs.SE
Towards Anticipation of Architectural Smells using Link Prediction Techniques
ISISTAN Research Institute, CONICET-UNICEN University（CONICET-UNICEN大学ISISTAN研究所）
软件系统会自然地进化，而这种进化经常会带来导致系统退化的设计问题。架构气味是此类问题的典型症状，其中一些气味与模块之间不希望的依赖性有关。早期检测这些气味对开发人员很重要，因为他们可以提前计划维护或重构工作，从而防止系统降级。用于识别架构气味的现有工具可以在气味存在于源代码中时检测到气味。这意味着已经创建了它们不需要的依赖关系。在这项工作中，我们探索了一种前瞻性的方法，能够推断出可能的模块依赖关系，可以预测在未来的系统版本的架构气味组。我们的方法将当前模块结构视为网络，以及来自以前版本的信息，并应用链接预测技术（来自社会网络分析领域）。特别是，我们专注于依赖相关的气味，如循环依赖和枢纽依赖，这很好地符合链接预测模型。对两个开源项目的初步评估表明，在某些考虑因素下，我们的方法的预测是令人满意的。此外，该方法可以扩展到其他类型的基于依赖性的气味或度量。
2018-08-20 cs.LG cs.SE
How Do Communities of ML-Enabled Systems Smell? A Cross-Sectional Study on the Prevalence of Community Smells
本研究通过分析188个开源ML仓库，发现社区异味（如Prima Donna Effects和Sharing Villainy）的流行度及时间变化，为ML项目经理改善团队协调提供支持。
2025-04-24 cs.SE
Technical Debt in Data-Intensive Software Systems
当今数据的数量、种类以及生成和处理速度的不断增加给数据密集型软件系统（DISS）的开发提出了各种新的挑战。与开发其他类型的软件系统一样，开发DISS通常是在严重的压力和严格的时间表下完成的。因此，DISS的开发人员经常不得不做出技术妥协，以满足业务需求。本立场文件提出了一个概念模型，概述了技术债务（TD）可以出现和扩散在这样的数据为中心的系统中，通过将DISS分为三个部分（软件系统，数据存储系统和数据）。此外，本文还通过两个实例说明了在以关系数据库为中心的软件系统中数据库模式气味作为TD项的扩散。
2019-05-31 cs.SE
SmellDoc: Extending Elastic Stack for Microservice Bad Smell Detection and Visualization
Faculty of Computing, Harbin Institute of Technology（哈尔滨理工大学计算机学院）
提出基于Elastic Stack的SmellDoc框架，通过集成检测、知识库和健康监控，结合静态与运行时分析检测24种微服务坏味，并在Kibana中可视化，以增强运行时可观测性并加速故障排除。
2026-05-23 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
Predicting Community Smells' Occurrence on Individual Developers by Sentiments
社区气味出现在次优的软件开发社区结构中，导致不可预见的额外项目成本，例如，生产力下降，技术债务增加。以前的研究分析和预测社区气味的粒度社区亚组使用社会技术因素。然而，重构这种气味需要开发人员单独努力。要消除这些障碍，必须根据其主题和工作状态，为每个开发人员制定相应的支持措施。最近的研究表明，开发人员的个性可能会影响社区气味的变化，他们的情绪可能会影响生产力。因此，情绪可以被评估来预测社区气味在他们身上的发生。为此，本文构建了一个面向开发人员的感知社区气味预测模型，考虑了组织筒仓，孤狼和瓶颈等3种气味。此外，它还预测开发商是否在受到任何气味影响后离开社区。所提出的模型实现了跨项目和项目内的预测F-测量范围从76%到93%。研究还发现，与活跃度指标相比，6个情感特征具有更强的预测能力。祈使语和指示性表达、礼貌和几种情绪是最有力的预测因素。最后，我们统计测试的平均值和分布的情感特征。根据我们的研究结果，我们建议开发人员应该以直接和礼貌的方式进行沟通。
2021-03-12 cs.SE
Crowdsmelling: The use of collective knowledge in code smells detection
代码气味被视为技术债务的主要来源，因此应该被检测和删除。然而，研究人员认为，代码气味检测过程的主观性是减轻气味感染代码问题的主要障碍。我们提出了基于监督机器学习技术的群众嗅觉方法，其中群众（软件开发人员）的智慧用于集体校准代码气味检测算法，从而减轻主观性问题。本文介绍了一个验证实验的结果，群众嗅的方法。在连续三年的软件工程课程的背景下，总共有大约100个团队的“人群”，每个团队平均有三名成员，将Java源代码中存在的3种代码气味（长方法，上帝类和功能嫉妒）分类。这些分类是用于训练六种机器学习算法的预言机的基础。生成并评估了100多个模型，以确定哪些机器学习算法在检测上述每种代码气味时具有最佳性能。God Class检测（Naive Bayes的ROC=0.896）和Long Method检测（AdaBoostM1的ROC=0.870）获得了良好的性能，但Feature Envy的性能要低得多（Random Forrest的ROC=0.570）。得到的结果表明，crowdsmelling是一种可行的方法，用于检测代码气味，但需要进一步的验证实验，以涵盖更多的代码气味，并增加外部有效性。
2020-12-23 cs.SE
On the correlation between Architectural Smells and Static Analysis Warnings
针对103个Java项目的实证研究分析了785种SAW与4种AS的相关性，并提出依据SAW严重程度和AS易发度排序修复优先级的方法。
2025-09-01 cs.DC cs.SE
Socio-Technical Well-Being of Quantum Software Communities: An Overview on Community Smells
University of Salerno（萨莱诺大学）
本文研究量子开源社区的社会技术福祉，分析社区异味问题及其对产品质量和可持续性的影响。
2026-02-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
The Dangers of Non-Self-Fixed Architecture Technical Debt and Its Impact on Time-to-Fix
Bernoulli Institute, University of Groningen（格罗宁根大学伯努利研究所）；Department of Information Systems, Telkom University（泰国电信大学信息系统系）
本文研究了非自修复架构技术债的修复责任及影响，通过分析开源项目发现自修复与非自修复技术债在修复时间和协作因素上有显著差异，为维护者提供识别高风险技术债和减少交接成本的指导。
2026-11-05 cs.SE
Measuring Technical Debt in AI-Based Competition Platforms
本文通过范围综述识别并分类AI竞赛平台中的技术债务类型，提出专门的可访问性债务概念，并开发问卷与管理框架以提升平台的可持续性和可维护性。
2024-08-01 cs.SE
Understanding Self-Admitted Technical Debt in Test Code: An Empirical Study
Nara Institute of Science and Technology（奈良先端科学技术大学院大学）；Hangzhou Dianzi University（杭州电子科技大学）
本研究通过实证分析揭示测试代码中自我承认技术债务的分布和类型，并开发机器学习模型进行自动分类，发现其与测试质量无直接关联。
2026-02-09 cs.SE
Quantitative Analysis of Technical Debt and Pattern Violation in Large Language Model Architectures
Georgia Institute of Technology（佐治亚理工学院）
本研究通过对比分析三种大语言模型在实现标准化微服务时的架构一致性与技术债务积累情况，揭示了开源模型在架构合规性方面的不足及潜在的技术债务风险。
2025-12-03 cs.AI cs.SE
Towards Quantifying Requirements Technical Debt for Software Requirements concerning Veracity: A Perspective and Research Roadmap
本文提出将需求技术债务（RTD）的量化视角应用于软件需求真实性，通过提出“真实性债务”概念和研究路线图，支持对涉及真相、信任与可证明性的需求进行债务管理。
2024-06-29 cs.SE
The Technical Debt Gamble: A Case Study on Technical Debt in a Large-Scale Industrial Microservice Architecture
本研究通过混合方法案例研究，揭示大规模微服务系统中技术债务的表现，提出静态分析可高效发现债务，并指出沟通不足与架构组织错位加剧债务，总结出管理策略。
2025-06-19 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
The Broken Windows Theory Applies to Technical Debt
本研究通过受控实验和混合方法，实证验证了破窗理论在软件工程中的适用性，发现高技术债务密度会显著增加开发者引入新债务的倾向。
2023-12-25 cs.SE
A Taxonomy for Understanding the Security Technical Debts in Blockchain Based Systems
区块链是一种颠覆性技术，旨在实现安全的分散式分布式系统，其中交易数据可以由系统的参与者使用加密和共识机制共享，存储和验证，从而提高了对中央认证/验证机构的需求。与人们的看法相反，基于区块链的系统在设计上并不是天生安全的;安全软件工程师必须了解各种区块链特定的架构设计决策和选择及其对软件系统可靠性的影响。我们认为，区块链组件及其配置的次优和不明智的设计决策和选择，包括智能合约，密钥管理，加密和共识机制，链上与链下存储选择，可能会将安全技术债务引入系统。技术债务隐喻可以作为一个强大的工具，通过使安全软件工程师看到潜在的安全技术债务，对基于区块链的系统的安全设计进行早期、预防性和透明的评估。我们回顾了基于区块链的系统的核心架构组件，并展示了这些组件的错误选择或次优设计决策和配置如何表现为安全技术债务。我们贡献了一个分类法，对区块链特定的设计决策和选择进行分类，并描述了它们与潜在债务的联系。该分类法可以帮助这类系统的架构师通过可视化安全技术债务并提高其可见性来避免潜在的安全风险。我们使用两个案例研究的例子来讨论分类法及其应用。
2019-03-08 cs.CR 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
Assuring the Evolvability of Microservices: Insights into Industry Practices and Challenges
虽然微服务承诺了可持续的长期软件演化的几个有益特征，但很少有实证研究涉及行业应用于微服务可演化性保证的具体活动以及如何在此类系统中处理技术债务。由于洞察到目前的实践状态是非常重要的研究人员，我们进行了定性访谈研究，探讨应用的可进化性保证过程，工具，指标和模式的使用，以及参与者的反思的主题。在17次半结构化访谈中，我们与来自10家公司的软件专业人员讨论了14种不同的基于微服务的系统，以及如何确保这些系统的可持续发展。访谈记录采用详细的编码系统和不断比较的方法进行分析。我们发现，特别是外部客户的系统依赖于中央治理来保证。与会者认为像架构原则这样的指导方针对于确保可演化性的基本一致性非常重要。受访者还重视手动活动，如代码审查或童子军，即使自动化和工具支持被描述为非常重要。源代码质量是使用工具和度量的主要目标。尽管大多数报告的问题都与架构技术债务（ATD）有关，但我们的参与者并没有应用任何架构或面向服务的工具和指标。虽然参与者普遍认为他们的微服务是可进化的，但服务切割和找到具有低耦合和高内聚的适当服务粒度被认为是具有挑战性的。未来微服务在演化和技术债务领域的研究应该考虑这些发现和行业情绪。
2019-06-12 cs.SE
Technical Debt Management Automation: State of the Art and Future Perspectives
本文通过系统映射研究梳理技术债务管理自动化的工具、插件、脚本与机器人现状，并提出概念模型指出制品集成是实现全自动TDM的关键挑战。
2023-11-30 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
Exploring the Relationship Between Ownership and Contribution Alignment and Code Technical Debt
本文通过大型软件系统案例研究，探讨了所有权与贡献一致性和代码技术债务密度的关系，发现较高的贡献一致性和最小化团队间依赖有助于控制代码质量退化。
2024-06-26 cs.SE
Stakeholder Criteria in Technical Debt Decision-Making: A Practitioner-Informed Taxonomy
Federal University of Bahia（巴伊亚联邦大学）
基于对11名软件实践者的定性研究，提出利益相关者在技术债务决策中使用的六类标准（如交付压力、技术完整性等），并区分了获取与偿还的不同决策功能。
2026-06-23 cs.SE
Towards the Assisted Decomposition of Large-Active Files
紧密耦合和相互依赖的系统要求开发人员仔细协调他们的更改，甚至在修改应该相互独立的子系统时也是如此，从而抑制了生产力。糟糕的体系结构决策经常导致出现大型的、易更改的源文件，这些文件是复杂的技术债务的中心。这种技术债务通过协调成本和错误倾向很快引起了人们的兴趣。在本文中，我们提出了一种新的方法来分解这些“大型活动”文件，以偿还关键的技术债务。我们将我们的方法打包为一个重构推荐系统。每个建议都是通过分析文件之间的共同更改和相互依赖的模式来确定的。每个建议对应于大型活动文件相对于系统其余部分的责任。通过将推荐的功能从大型活动文件移动到较小的文件中，开发人员可以减少负债累累的文件的影响，并阐明其基本职责。与以前的工作相比，这种方法的一个关键优势是我们可以更好地集中精力;我们避免了花费开发人员的精力来重构那些只是表面上有问题的代码。我们通过将修订历史纳入确定和排名建议来实现这一点。每个建议都对应于一些易于更改的职责。我们提出了一些这种方法在行动中的例子，并概述了我们未来的计划。
2023-02-17 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
Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use
Tampere University（坦佩雷大学）；University of Derby（德比大学）；Koivu Solutions；Aimbition
本文探讨了Vibe编码在实践中的应用，分析了其与技术债的权衡，并提出了可持续使用的指南和对策。
2025-12-11 cs.AI cs.SE
On AI Safety and Security Technical Debt in Engineering AI-Enabled Systems
University of Birmingham（伯明翰大学）；HBKU（哈马德·本·哈利法大学）；Bournemouth University（伯恩茅斯大学）；Brunel University London（伦敦布鲁内尔大学）；University of Hawaii（夏威夷大学）；College of Science and Engineering, HBKU（哈马德·本·哈利法大学科学与工程学院）
研究人工智能系统工程中的安全与保障技术债务，通过系统综述识别31种AITD并分类，分析其与信任问题的关联，合成34条指南，引入AITD - MAP框架，助工程师应对AITDs。
2026-07-28 cs.AI cs.CR cs.SE
