AsystematicliteraturereviewonTechnicalDebtprioritization:Strategies,processes,factors,andtools

本文对技术债务优先级的系统文献进行了详尽的回顾,概述了不同的优先化策略,如提升软件质量、生产力、正确性、成本效益分析和综合方法。研究揭示了实践中考虑的多种因素,但缺乏统一的方法和成熟的工具,强调了未来在理解和量化利息方面的必要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

关于技术债务优先顺序的系统文献综述:战略、过程、因素和工具

目录

关于技术债务优先顺序的系统文献综述:战略、过程、因素和工具

摘要

1 介绍

2 技术债务优先化思维导图

3背景

3.1 技术债务

3.2 先前的系统文件回顾

4 方法论

4.1 目标和研究问题

4.2 检索策略

4.4 数据抽取

4.5 可复现性

5 结果

5.1 RQ1 提出过哪些优先化策略?

5.1.1 内部软件质量

5.1.2 软件生产力

5.1.3 软件正确性

5.1.4 成本效益分析

5.1.5 不同方法的结合体

5.2 RQ2论文是优先考虑 TD vs. TD 还是 TD vs. features?

5.3 RQ1.2 优先级是基于一次性活动还是基于连续过程?

5.4 RQ2 TD优先级考虑了哪些因素和措施?

5.3 RQ3哪些工具已被用于TD优先化

6 讨论

7 有效性威胁

7.1 结构有效性

7.2 内部有效性

7.3 外部有效性

7.4 结论有效性

8 结论


摘要

背景

软件公司需要管理和重构技术债务问题。因此,有必要了解技术债务的重构是否以及何时应该优先考虑开发特性或修复bug。

客观

本研究的目的是调查在工程设计中现有的软件知识体系,以了解在科研和工业界中提出了哪些技术债务优先化的方法。

方法

我们对截至2020年发表的557篇独特论文进行了系统的文献回顾,遵循应用于软件工程的整合方法。我们总结了44项基本研究。

结果

针对技术债务优先顺序提出了不同的方法,所有方法都有不同的目标,并针对不同的标准提出了优化建议。拟议的措施只涵盖了实践中用于定性优先技术债务的过多因素中的一小部分。我们展示这些因素的影响图。然而,缺乏经验和有效的工具。

结论

我们观察到,技术债务优先化研究尚处于初步阶段,目前在重要因素是什么以及如何衡量这些因素上尚未达成共识。因此,我们不能认为当前的研究有决定性。因此,在本文中,我们概述了必要的未来研究方向。

1 介绍

技术债务 (TD) 是 Cunningham (1992) 引入的一个比喻,用于表示次优设计或实施解决方案,这些解决方案在短期内会产生收益,但在中长期内会使更改成本更高甚至不可能(Avgeriou 等 等人,2016b)。 软件公司需要管理这样的次优解决方案。TD的存在是不可避免的 (Martini et al., 2015),在某些情况下甚至是可取的 (Besker et al., 2018c),原因有很多,这通常可能与组织的内部或外部的不可预测的业务或环境因素有关。

但是,就像任何其他金融债务一样,每个TD都附带利息,否则产生额外成本或负面影响,这是由于存在次优解决方案而产生的(Li et al., 2015)。 当这种利息变得非常昂贵时,它可能导致破坏性事件,例如发展危机(Martini 等,2015)。软件公司当前采用的最佳实践包括避免TD,如果后果已知或重构或重写代码和其他工件,以摆脱累积的次优解决方案及其负面影响。公司无法避免或偿还所有持续产生且可能未知的TD(Martini 等人,2015 年)。 公司的主要业务目标是持续为客户创造价值并维护他们的产品。

因此,TD 重构活动通常与用于开发新功能和修复缺陷的时间分配相竞争,其中TD重构活动通常优先于新功能的实现(Martini 等,2015)。 因此,了解何时重构TD变得比推迟一个特性或bug修复更重要。换句话说,重要的是要了解如何根据功能和错误对TD进行优先级排序。 然而,最近在几家软件公司进行的一项研究(Besker 等人,2019 年)报告了公司如何努力优先考虑 TD,并且他们不使用系统方法。 这引出了我们的第一个研究问题:提出了哪些优先级策略?(RQ1)回答此RQ将提供已研究的优先级策略列表,这对于从业者改进实践和确定更适合其目标的策略很有用。

此外,最近的研究表明,不同的项目甚至不同类型的TD可能如何与不同的重构成本(本金)和负面影响(利息)相关联(Besker 等人,2018b)。 但学术界和工业界仍不清楚如何衡量本金和利息,以及哪些工具可以帮助这些活动。 然后我们制定其他 RQ:TD 优先级考虑了哪些因素和措施?(RQ2) 以及哪些工具已被用于确定TD的优先级? (RQ3)

再次,回答这些问题将为从业者提供可操作的措施和工具来量化或至少估计本金和利息,从而优先考虑 TD。

此外,作为与 RQ1 相关的优先级策略的一部分,我们知道一些TD可能比其他的更危险(Seaman 等人,2012;Martini 和 Bosch,2016c),因此在考虑其他TD的情况下,理解如何优先考虑TD变的很重要。 因此,我们提出以下 RQ,以了解哪些方法可用以及哪些方法缺失:论文是优先考虑TD与TD还是TD与功能?(RQ1.1) 另一个与TD优先排序策略相关的重要方面是其周期性,例如,优先排序既可以作为一次性活动完成,也可以迭代完成并作为连续过程。

因此,我们提出了 RQ:优先级是基于一次性活动还是基于连续过程? (RQ1.2)。 这个研究问题的重点是如何在审查过的出版物中根据其周期性来描述优先排序过程。我们根据一次性活动与连续过程的一部分来区分不同的方法。

然而,没有全面的研究来调查TD优先级的策略、过程、因素和工具。 唯一类似的工作(Alfayez 等人,2020 年)仅根据其对价值和成本的考虑分析了优先级排序方法。

我们在本文中的目标是调查软件工程中现有的知识体系,以了解科研界和工业界中已提出哪些方法来优先考虑 TD。出于这个原因,我们对TD的优先级进行了系统文献回顾 (SLR)。 我们进行了 SLR 以调查软件工程中现有的知识体系,以了解软件组织中TD的优先级以及已提出哪些研究方法。

本文的主要贡献是一份关于在实践中使用或在研究中提出的优先处理TD的方法、因素、措施和工具的最新报告。

本文结构如下:在第 3 节中,我们描述了这篇综述的背景。 在第 4 节中,我们概述了本研究中采用的研究方法。 第 5 节和第 6 节介绍并讨论了获得的结果。 最后,在第 7 节中,我们确定了对有效性的威胁,并在第 8 节中得出结论。

2 技术债务优先化思维导图

我们提出了一个初步的思维导图来概念化我们的目标和研究问题,这可以在 TD 优先级活动中帮助从业者,如图 1 所示。这个思维导图提供了对 TD 优先级过程中需要考虑的不同因素的探索 以及这些因素如何相互关联。

第一步是确定从业者是否需要优先考虑 TD 问题中的重构,或者他们是否需要优先考虑 TD 重构,相较于新功能和错误修复的实现(回答 RQ1)。 这是因为这些方法在评估 TD 的影响以及评估功能和错误的价值或影响方面有所不同。 在前一种情况下,优先级方法可以使用相同的因素,而在后一种情况下,TD的本金和利息更可能需要与面向特征的因素进行比较,例如竞争优势或延迟成本。

一旦确定了比较的范围,TD 的评估应考虑以下因素:(1) TD 本金的差异(解决问题的成本),(2) 影响(TD 利息),以及 (3) 其他因素,包括经济和营销因素(RQ2 的结果)。

评估可以是定量和定性的(RQ1),在某些情况下可以得到工具的支持(RQ3)。 例如,公司可能会使用工具对代码债务的存在进行定量评估,但他们可能还需要对无法使用工具衡量的因素进行定性评估(例如,通过代码审查),例如考虑代码可读性、可分析性、 或其他质量特征。 此外,一些工具提供了计算TD本金的方法,但从业者可能需要通过定性评估影响因素来计算利息。

此外,评估应该考虑不同的场景,包括可用资源和系统的可能演变。 事实上,TD 可能非常依赖于上下文(正如我们在 RQ3 中讨论的影响因素),这意味着从业者需要通过对未来情景的估计来评估它。 例如,在工具 AnaConDebt 中,从业者可以指定在短期、中期或长期情景中发生的事件。 不同场景的评估应该有助于做出重构决策,例如关于应该执行哪些重构以及应该推迟哪些重构。

作为决策过程的一个示例,公司可能会考虑不实施涉及受 TD 影响的代码部分或模块的新功能。 如果估计此类 TD 在短期场景中会产生高兴趣,则可能会发生这种情况:在这种情况下,TD 产生的兴趣可以克服延迟功能的成本。 然后,从业者可能会决定在实现该功能之前重构代码。

让我们举一个具体的例子,说明如何按照优先级思维导图中的步骤做出重构决策。 架构师需要在开发更多访问它的应用程序之前决定是否重构“次优”接口。 架构师的主要活动是评估是否优先考虑 TD 的重构与开发新功能。 然后架构师需要考虑和计算不同的因素(本金、利息和其他因素)。 如果没有重构,TD 将传播到所有新代码(传染性债务)。 此外,所有新应用程序都会受到与次优 API 交互产生的负面影响(兴趣)(系统中的影响传播。尽管延迟新应用程序的开发(面向特征的因素)将意味着成本) 在短期情况下,由于开发人员不会支付次优接口产生的利息,因此可以减少长期情况下开发新功能的准备时间。如果这种长期收益克服了成本 在延迟应用开发的情况下,从业者应该选择对 API 进行重构,这种情况下,重构决定将通过评估在未来的场景中,避免利息的成本是否值得支付本金来做出。

TD 优先级思维导图可以结合本文中介绍的其他结果(影响图、优先级方法描述和可用工具)帮助从业者做出重构决策。

3背景

在本节中,我们解释 TD 的含义以避免混淆或误解,我们将报告以前发表的系统评价。

3.1 技术债务

TD 的概念是由 Cunningham 于 1992 年首次引入的,它是“通过加速软件项目开发而产生的债务,导致许多缺陷最终导致高昂的维护费用”(Cunningham,1992) . 2013 年,McConnell (2013) 将 TD 的定义改进为“一种设计或施工方法,在短期内是权宜之计,但会创造一种技术环境,在这种环境中,同样的工作在后期完成的成本将高于完成的成本。 现在(包括随时间增加的成本)''。 2016 年,Avgeriou 等人。 (2016a) 将其定义为“一组设计或实施结构,这些结构在短期内是权宜之计,但建立的技术环境可能会使未来的改变成本更高或不可能实现。 TD 是一种实际或或有负债,其影响仅限于内部系统质量,主要是可维护性和可演化性”。

李等人。 (2015) 进行了系统的映射研究,以了解 TD 的概念,并概述了管理 TD 的研究现状。 根据选定的研究 (96),他们提出了 10 种不同级别的 TD 分类,如表 1 所示。由于该分类源自最近的一项二级研究,据我们所知,这是最完整的分类 在文献中,我们在搜索策略过程(第 4.2 节)中考虑了它来定义我们的搜索词。

3.2 先前的系统文件回顾

 在本节中,我们简要报告源引擎中可用的以前的系统评论(系统映射研究和系统文献评论),显示它们的主要目标在表2)。 我们按时间顺序介绍这些研究,以展示有关 TD 的研究进展。 第一篇系统评价发表于 2012 年(Tom 等人,2013 年),据我们所知,最后一篇系统评价发表于 2018 年(Besker 等人,2018a;Rios 等人,2018 年)。

汤姆等人(2013)利用探索性案例研究技术,包括多语言文献回顾,辅以对软件从业者和学者的采访,以确定 TD 现象的边界。 结果,他们创建了一个理论框架,提供了 TD 的整体视图,包括一组 TD 维度、属性、先例和结果。 该框架提供了一种有用的方法来理解 TD 的整体现象,以用于实际目的。

李等人。 (2015) 调查了 TD 管理 (TDM),提供了 TD 概念的分类并介绍了 TDM 的研究现状。 他们考虑了 1992 年至 2013 年间的出版物,最终选择了 94 项研究。 结果表明,需要对 TDM 过程提供高质量证据的实证研究、TDM 方法在工业环境中的应用以及在 TDM 过程中管理不同 TD 类型的工具。

Ampatzoglou 等人。 (2015) 分析了有关 TD 的研究工作,重点关注软件工程概念的财务方面。 他们考虑了 2015 年之前的出版物,选择了 69 项研究。 结果提供了术语表和用于管理 TD 的财务方法的分类方案。此外,他们发现财务和软件工程概念之间缺乏清晰的映射。

里贝罗等人。 (2016) 评估了支付 TD 项目的适当时间以及如何应用决策标准来平衡短期收益与长期成本。 他们考虑了 2016 年之前的出版物,选择了 38 项研究。 他们确定了 14 个决策标准,开发团队可以使用这些标准来确定 TD 项目的优先级,以及与标准相关的债务类型列表。

阿尔维斯等人。 (2016) 调查了在软件项目中识别和管理 TD 的建议策略,考虑了 2010 年至 2014 年间的出版物并选择了 100 项研究。他们提出了 TD 类型的初步分类,并提供了一个指标列表来识别 TD 和管理策略。此外,他们分析了 TD 的当前状态,突出了可能的研究差距。 结果表明,研究人员对 TD 领域的兴趣日益浓厚。 他们发现了一些关于新指标建议和管理战略以及控制 TD 工具的差距。 他们发现的另一个差距是关于验证提议策略的实证研究.。

费尔南德斯-桑切斯等人。 (2017) 确定了管理 TD 所需的要素,考虑到 2017 年的出版物并选择了 69 项研究。 他们没有提供关于 TD 现象或管理 TD 活动的一般概述。这些要素分为三组(基本决策因素、成本估算技术、实践和决策技术),并根据利益相关者的观点(工程、工程管理和业务组织管理)进行分组。) .

贝胡蒂耶等人。 (2017) 在敏捷软件开发 (ASD) 的背景下分析了 TD 的最新技术及其原因、后果和管理策略。 他们考虑了 2017 年之前的出版物,并选择了 38 项研究,寻找潜在的研究领域进行进一步调查。 该研究强调了对 TD 和 ASD 的积极兴趣,并提供了一些很容易导致 TD 的潜在类别,例如“专注于快速交付以及架构和设计问题”。

贝斯克等人(2018)整理和整理研究工作,以创造对 ATD 有特殊兴趣的新知识。 他们考虑了 2005 年至 2016 年间的出版物,选择了 43 项研究。 结果表明,缺乏关于如何在实践中成功管理 ATD 的指导方针以及这些活动完全整合的整体过程。

里奥斯等人。 (2018 年)基于一组五个研究问题进行了第三项研究,并评估了 2012 年至 2018 年 3 月的 13 项二次研究。他们发展了 TD 类型的分类法,确定了在软件项目中可以找到债务项目的情况列表 ,并组织了一张地图,代表了支持 TD 管理的活动、策略和工具的最新状态。 他们的结果可以帮助确定在 TD 研究中仍需要进一步调查的点。 例如,他们发现有些管理活动没有任何类型的支持工具。

霍米亚科夫等人。 (2019) 研究了用于测量和分析 TD 的现有工具,重点关注也可以自动化的定量方法。 他们从检索到的 331 篇论文中选出了 21 篇。 他们的结果表明,正在定义许多新方法来测量 TD。

Avgeriou 等人。 (2020) 比较了现有的测量 TD 的工具,比较了它们的特征和流行度,并分析了现有的经验证据来证明它们的有效性。 与这项工作不同的是,他们没有比较优先考虑 TD 的方法。

最近,Alfayez 等人。 (2020) 调查了软件工件的依赖关系,以及所需人工参与的类型。

他们根据对价值、成本或资源限制的说明分析了优先级排序方法。

与现有的 SLR 相比,我们的研究是唯一一项研究 TD 优先级的策略、过程、因素和工具的研究,考虑到所有可能的方面,而不是只关注特定方面(例如努力 Ribeiro 等人,2016;Alfayez 等人,2020 年,或开发过程 Behutiye 等人,2017 年)。

4 方法论

为了了解技术债务优先级的最新技术和实践,我们根据 Kitchenham 和 Charters (2007) 以及 Kitchenham 和 Brereton (2013) 定义的指南进行了系统的文献回顾。 我们还应用了 Wohlin (2014) 定义的“滚雪球”过程。

在本节中,我们描述了目标和研究问题(第 4.1 节)并报告了我们的搜索策略方法(第 4.2 节)。 此外,我们对每篇包含的论文进行了质量评估(第 4.3 节),并概述了相应数据的数据提取和分析(第 4.4 节)。

4.1 目标和研究问题

根据我们的思维导图,研究目标是调查软件工程中现有的知识体系,以了解软件组织中 TD 如何优先考虑以及提出了哪些研究方法。

根据我们的目标,我们定义了以下研究问题(RQs)

 第一个研究问题针对所调查的研究论文如何从不同的策略(RQ1)方面解决 TD 的优先级排序过程,即 TD 的优先级排序过程是主要关注不同的 TD 项目还是还包括 TD 项目,例如,新功能的实施 (RQ1.1),以及如何根据周期性 (RQ1.2) 描述优先级过程。

基于上述 RQ,我们旨在确定在 TD 优先活动 (RQ2) 中被认为有用的一组因素和措施。 此外,我们旨在了解在确定主要 TD 组成部分、本金和利息的优先级时考虑了哪些措施。 我们的目标是提供用于评估 TD 的现有工具列表,以便从数量和每个工具的成熟度 (RQ3) 方面描述当前情况。

4.2 检索策略

检索策略包括最相关的书目来源和检索词的概述、纳入和排除标准的定义以及与纳入决定相关的选择过程。 我们的搜索策略如图 2 所示。

搜索词。 在我们的搜索字符串中,我们包含了 Li 等人提出的所有与 TD 相关的术语。 (2015 年)并在表 1(第 3 节)中报告。

搜索字符串包含以下搜索词:(''technical debt'')OR (''design debt'') OR (''architect* debt'') OR (''test* debt'') OR ('' 实施*债务'')或(''文件*债务'')或(''要求债务'')或(''代码债务'')或(''基础设施债务'')或(''版本债务' ') OR (''defect debt'') OR (''build debt'') 我们使用星号字符 (*) 表示第二个术语组,以便捕捉可能的术语变体,例如复数和动词变位。 为了增加找到解决 TD 优先级的出版物的可能性,我们将搜索字符串应用于标题和摘要。

书目来源。 我们根据 Kitchenham 和 Charters (2007) 的建议选择了相关书目来源列表,因为这些来源被认为是软件工程领域中最具代表性的来源,并在许多评论中使用。 该列表包括:ACM 数字图书馆、IEEEXplore 数字图书馆、Science Direct、Scopus、Google Scholar、CiteSeer 图书馆、Inspec、Springer 链接。 此外,我们手动搜索了最重要的技术债务会议和研讨会,例如国际技术债务会议 (TechDebt)。

 纳入和排除标准。 我们定义了适用于标题和摘要 (T/A) 或全文 (F) 或两种情况 (All) 的纳入和排除标准,如表 3 所示。

搜索和选择过程。 搜索于 2019 年 12 月进行,包括在此期间可用的所有出版物。 检索词的应用返回了 557 篇独特的论文。

测试纳入和排除标准的适用性:在应用纳入和排除标准之前,我们在从检索到的论文中随机选择的 10 篇论文(分配给所有作者)的子集上测试了它们的适用性(Kitchenham 和 Brereton,2013)。

将纳入和排除标准应用于标题和摘要:我们将改进的标准应用于剩余的 547 篇论文。 每篇论文由两位作者阅读; 在分歧的情况下,第三位作者参与讨论以澄清任何此类分歧。 对于 29 篇论文,我们涉及第三作者。在最初的 557 篇论文中,我们根据标题和摘要收录了 116 篇。

完整阅读:我们完整阅读了按标题和摘要包含的 117 篇论文,应用表 3 中定义的标准,并将每篇论文分配给两位作者。 我们让第三作者参与了六篇论文的最终决定。 基于此步骤,我们选择了 49 篇论文作为可能相关的贡献。

滚雪球:我们执行滚雪球过程(Wohlin,2014),考虑检索到的论文中提供的所有参考文献,并评估所有引用检索到的论文,从而产生了一篇额外的相关论文。 我们应用了与检索到的论文相同的过程。 滚雪球式搜索是在 2019 年 12 月进行的。我们只确定了 11 篇潜在论文,但为了撰写最终的出版物集,只收录了其中一篇。

根据搜索和选择过程,我们共检索到 50 篇论文进行审查,如表 5 所示。

 4.3 质量评估

在进行审查之前,我们检查了所选论文的质量是否足以支持我们的目标以及每篇论文的质量是否达到一定的质量水平。 我们根据 Dybå 和 Dingsøyr (2008) 提出的协议执行此步骤。 为了评估选定的论文,我们准备了一个包含一组具体问题的清单(表 4)。 我们对每个答案进行排名,并在李克特五点量表上打分(0 = 差,4 = 优秀)。 如果一篇论文的评分高于(或等于)2,则该论文符合质量评估标准。

 在检索和选择过程中纳入审查的 50 篇论文中,只有 44 篇符合质量评估标准,如表 5 所示。

4.4 数据抽取

我们从满足质量评估标准的 44 项主要研究 (PS) 中提取数据。 表 6 总结了数据提取表以及回答每个 RQ 所需信息的映射。

为了回答 RQ1,我们首先提取与论文上下文相关的数据,根据 Li 等人提出的列表,根据评估的 TD 类型概述每个 PS。 (2015 年)。 我们还报告了论文中采用的评估类型,区分了定性、定量和混合评估方法。 此外,我们还提取了删除、重构或修复 TD 问题的标准。

我们提取了与优先级目标(RQ1.1)相关的数据,以便了解论文是优先考虑 TD vs. TD 还是 TD vs. 新功能的实现。 为了回答 RQ1.2,我们报告了优先级是基于一次性活动,还是基于连续过程,如果它是主动的还是被动的。

为了回答 RQ2,我们提取了用于评估 TD 问题优先级的措施和因素,以及在优先级确定过程中建议的哪些指标。

最后,为了回答 RQ3,我们检索了有关用于评估和优先处理 TD 诉讼的框架和工具的信息。 这些数据完全基于论文中的报道,没有任何个人解释。

4.5 可复现性

为了允许其他研究人员复制和扩展我们的工作,我们为这项研究准备了一个复制包1,并获得了完整的结果。

5 结果

 根据采用的选择过程,我们确定了 44 项初步研究 (PS)。 考虑到表 1 中报告的 TD 类型,PS 中最常考虑的 TD 类型是:代码债务 (38%)、建筑债务 (24%) 和设计债务 (10%)。

此外,一些 PS (24%) 不报告任何特定 TD 类型的问题,而是对 TD 进行总体评估(图 3)。

通常从其对一种或多种软件质量的影响的角度来研究代码 TD [SP13]、[SP18]、[SP19]、[SP26]。 PS 最常考虑可维护性 [SP4]、[SP5]、[SP11] 和维护工作 [SP1]、[SP2]、[SP11]、[SP19]。 代码债务评估主要基于代码气味 [SP2]、[SP5]、[SP11]、[SP18]、[SP19]、[SP26]。

还考虑了其​​他指标,例如修复违规所需的时间 [SP4]、[SP23] 或成本 [SP1],以及质量规则 [SP13]。

一些与主观评估相关的因素,例如客户反馈 [SP23] 或代码中的开发人员评论 [SP28],评估的频率较低。

这些方法主要涉及通过删除或重构代码异味或其他指标来减少 TD 的模型 [SP11]、[SP18]。

这些方法着眼于对代码异味的影响 [SP5],与没有异味的类 [SP2]、[SP26] 进行比较,或者对开发人员认为关键的代码规则 [SP13] 进行排名。

考虑到架构气味 [SP17]、[SP19]、[SP20] 或复杂架构设计 [SP17]、[SP27] 对软件质量的负面影响 [SP17]、[SP19]、 [SP20]。 架构 TD 通过测量用于修复错误 [SP17] 或分析代码的错误倾向 [SP17] 的额外维护工作量来评估。 另一种方法结合了三种不同的观点,例如历史项目数据、架构设计和优先级重构活动的类的严重性 [SP19]。

架构设计用于识别与架构 TD [SP27] 相关的浪费时间方面的高度兴趣,并结合其他指标,例如文件数量和复杂功能和文件的百分比 [SP35]。

另一种方法识别架构组织之间的依赖关系和社会差距,以定义架构 TD [SP31]。

5.1 RQ1 提出过哪些优先化策略?

TD 优先级被认为是管理 TD 时最重要的活动之一。 TD 优先级流程用于定义计划重构计划的排序和/或调度,基于每个已识别的 TD 项目的优先级,这些项目涉及各个项目对软件的影响。

研究人员在审查的出版物中提出了几个不同的优先级方面,并且已经开发了一些关于如何优先级 TD 的方法,但是对于如何执行 TD 优先级过程没有统一的方法,也没有就哪一个达成共识 执行 TD 优先级流程时要关注的方面。 目前,在大多数组织中,优先级策略的选择取决于上下文 [SP21]。

为了分析检索到的出版物中提出的优先事项,使用了主题分析方法。主题分析是在搜索的数据范围内识别、分析和报告模式和主题的有效方法(Braun 和 Clarke,2006 年)。 主题分析主要返回了五个主题,说明了不同的优先级方面。但是,应该注意的是,从软件演化的角度来看,这些方面可能具有依赖性和耦合性。

根据分析,审查出版物中提出的不同建议优先级策略主要是:(a)提高软件质量,(b)提高软件从业者的生产力,(c)对软件正确性的影响,(d)成本- 收益分析 (CBA) 以比较各种 TD 项目的低成本和高回报,或 (e) 几种不同方法的组合。

 这些不同的策略与代表每种策略的出版物一起显示在图 4 中。

以下小节将更详细地描述每个被调查的出版物如何有助于 TD 策略的图解分类

5.1.1 内部软件质量

将内部软件质量作为优先策略的研究通常侧重于软件质量评估,以确定导致最高维护成本的 TD 项目 [SP1]、[SP2]、[SP13]、[SP19]、 [SP28]、[SP26]、[SP4],图 4. 技术债务优先策略。

[SP31]、[SP35]、[SP41]、[SP44],以及剩余产品寿命、债务严重程度及其对未来发展活动的影响以及当前与业务相关的限制等因素 [SP3]、[SP9] .

肖等人。 [SP17] 提出了一种专注于架构 TD 的方法。 它既侧重于定位 TD 项目,也侧重于对它们进行排序和优先级排序。 他们的方法返回消耗最大维护工作的 TD 项目,因此在重构 。

Plösh 等人时值得更多关注和更高优先级。 提出了一种 TD 优先级方法,主要关注设计债务的优先级,他们的方法依赖于通过将识别的 TD 项目转移到投资组合矩阵 [SP42] 来量化设计最佳实践。Albarak 和 Bahsoon 进一步声称,具有低于第四范式的数据库表的软件系统很可能形成 TD,因此应该优先考虑重构不规范化的表 [SP40]。

5.1.2 软件生产力

一些审查过的出版物在优先考虑 TD 时也考虑了软件从业人员生产力的下降,因为遭受架构 TD 的软件,例如,通过导致返工 [SP2],[SP3] 减慢了开发速度。

5.1.3 软件正确性

 TD 对软件正确性的影响被描述为一种评估不同候选 TD 项目以进行优先排序的方法 [SP2]。 更具体地说,Arcelli Fontana、Ferme 和 Spinelli [SP5] 报告说,可以通过研究代码气味重构对代表设计债务的影响来评估重构代码气味的优先级不同的质量指标,目标是识别和优先考虑“最危险的气味,因此代表最差 TD 的气味”。 在优先考虑缺陷债务时,特别是 Ak barinasaji 等人。 [SP23] 将他们的方法重点放在债务项目的严重性(使用关键、主要、正常和次要的分类)和 bug-xing 时间的持续时间上。

Codabux 等人。 [SP21] 使用贝叶斯方法建立预测模型,根据评估单个项目风险的 TD 倾向概率,使用分类方案确定每个 TD 项目的“TD 倾向”。

5.1.4 成本效益分析

[SP3]、[SP6] 等研究人员在对不同的 TD 项目进行优先排序时使用成本效益分析,重点关注应该首先执行哪些重构活动,因为它们实施起来可能成本低廉但效果显着, 由于成本高、回报低,重构应该推迟。 这种方法的主要重点是对软件进行有利可图的投资,该分析的输出是按不同可能重构活动的盈利能力排序的不同 TD 项目的优先列表 [SP3]。

Martini 等人赞同这一策略。 [SP32],他说“如果利息很高(或将要很高),那么债务是值得偿还的。 相反,如果利益不足以证明重构的成本是合理的,则没有理由“浪费资源重构系统”。 然而,马提尼等人。 [SP32] 还强调不仅要通过单独评估每个 TD 项目来将优先级决策集中在单个 TD 项目上,而且要了解 TD 项目对整个项目的总体影响,从而通过评估项目来关注项目的总体目标。 整体信息。 在这种方法中,Martini 等人。 [SP32] 还包括受 TD 影响的代码部分、项目规模、路线图、TD 的积极影响、替代方案的存在以及团队在优先考虑 TD 重构活动时的文化态度等因素 .

5.1.5 不同方法的结合体

相当多的调查出版物提出了几种不同方法的组合。 例如,Alfayez 和 Boehm [SP44] 提出了一种基于自动搜索的方法,使用称为 MOEA(它是一个开源 Java 库)的多目标进化算法对 TD 进行优先排序,重点是偿还 TD 重构活动 在特定的成本限制范围内。

Seaman 等人借鉴了金融和心理学等其他学科的优先排序方法。 [SP6] 包括层次分析法 (AHP)、投资组合方法和期权方法等技术。 AHP 方法包括建立标准层次结构,为标准分配权重和尺度,最后在备选方案与各种标准之间进行一系列成对比较。 使用投资组合方法的目标是选择那些最大化投资回报或最小化投资风险的资产。

Codabux 等人。 [SP25] 强调对优先排序过程采取更广泛视角的重要性,重点关注 TD 的责任。 据他们说,决策者需要考虑的不仅仅是与修复债务相关的成本,包括对决定发货可能产生的未来成本的估计。 在责任成本方面的优先排序过程中反映的额外成本包括,例如,响应支持请求的成本、与灾难性故障相关的成本等,以及由于无法管理的债务而违反服务水平协议时的潜在诉讼成本。

里贝罗等人。 [SP24] 提出了一个多决策策略标准模型,它结合了不同的优先级方法,可用于不同的项目阶段。他们的模型侧重于诸如 TD 项目从客户角度对 TD 利息成本的影响的严重性、项目属性的生命周期及其演变的可能性等方面。

另一个包含不同视角的优先排序过程是 Ciolkowski 等人描述的方法。 [SP29]。他们的方法侧重于将整体软件质量与从面向未来的角度关注生产力提高相结合,使用积极主动的方法。

古普塔等人。 [SP20] 使用两级方法对 TD 进行优先排序。 首先,TD项目根据其重要性和紧迫性进行评估。 第二步,评估 TD 项目对业务价值和努力的影响。

郭等人。 [SP15] 提出了一种 TD 优先级方法,该方法根据最高优先级对客户期望进行排序,其次是开发资源的可用性、TD 项目的兴趣、受债务影响的模块的当前状态以及债务对其他功能的影响 . 通过研究软件从业者在实践中如何优先考虑 TD 项目,Yli-Huumo 等人。 [SP14]、[SP16] 得出的结论是,他们的优先级划分方法通常侧重于可扩展性、业务价值、功能的使用和客户效应。

狙击手等人。 [SP7] 提出了一种 TD 优先级排序方法,该方法包括多种因素,例如严重性、是否存在变通方法、客户要求重构的紧迫性、重构工作量、建议重构的风险以及所需的测试范围 .

Schmid [SP8] 区分了潜在 TD 和有效 TD,其中潜在 TD 是任何类型的次优软件系统,而有效 TD 是指软件系统中使该系统的进一步开发更加困难的问题。 这种优先级划分方法考虑了诸如进化成本、重构成本以及预测的进化路径将实现的概率等方面。

此外,Almeida 等人。 [SP43] 建议在对 TD 进行优先排序时也关注业务目标,以支持业务期望和目标。 研究人员比较了技术优先级和面向业务的优先级之间的差异,他们表示,他们的结果表明“考虑业务优先级可以改变与技术债务优先级相关的决策”。 这个优先级方面也被描述为便于从技术方面进行论证,从而说服业务利益相关者优先考虑以前被认为是纯技术问题的问题。

Martini 和 Bosch [SP33] 提出了一个名为 AnaConDebt 的工具,用于在 TD 优先级排序过程中提供帮助。 他们的工具评估不同 TD 项目的兴趣严重程度,兴趣的计算基于对七个不同因素及其增长的评估。 评估的因素是:(1) 降低开发速度,(2) 与 TD 项目相关的错误,(3) 其他质量受损,(4) 其他额外成本,(5) 问题频率,(6) 在 系统,以及 (7) 受影响的用户。 维达尔等人。 [SP18] 还提出了一个名为 JSpIRIT 的工具,用于专门确定与源代码相关的 TD 的优先级,其中 TD 项根据不同的优先级标准根据其重要性进行评估。 该工具根据其重要性计算一组代码气味的排名,其中该工具可以实例化以按不同标准对 TD 项目进行优先级排序。 此类标准的示例包括代码气味类型的相关性、系统的历史或不同的软件指标等。 此外,开发人员可以使用外部信息来提高优先级。

另一个经过审查的出版物 [SP39] 建议使用称为 CodeScene 的工具执行 TD 优先级,其中考虑了开发人员如何使用代码等因素。 该过程在计算已识别 TD 项目的基于缩进的复杂性时使用复杂性趋势分析,并与熟练的人类观察者一起确定最终的 TD 优先级。

5.2 RQ2论文是优先考虑 TD vs. TD 还是 TD vs. features?

由于当今的软件公司在交付客户价值方面面临越来越大的压力,因此在将开发人员的时间、精力和资源用于实施新功能或将其用于 TD 补救活动、修复错误或其他系统改进之间取得平衡变得至关重要。 在这项研究中,我们将范围限制在研究优先实施新功能或修复现有 TD 之间的平衡。

总之,本研究问题旨在解决 TD 优先级过程是否主要关注不同 TD 项目之间的优先级,或者 TD 项目是否被描述为与新功能的实现竞争。

预算、资源和可用时间是软件项目中的重要因素,尤其是在确定优先级的过程中,因为在重构活动上花费时间和精力通常意味着可以花费更少的时间来实现新功能,例如。 这是软件公司并不总是在 TD 重构上花费额外预算和精力的主要原因之一,因为它们通常非常关注提供客户可见的功能 [SP18]。

Ciolkowski 等人。 [SP29] 这样描述这种情况:“项目经理面临的挑战是在使用给定的预算和进度时找到平衡点,要么减少 TD,要么增加技术特性。 需要这种平衡来保持当前产品发布的上市时间较短,并将未来的维护成本保持在可接受的水平”。 赞同这种观点,即“理想的盟友,应根据技术债务利率优先考虑可操作的重构目标,以平衡改进、风险和新功能之间的权衡”[SP39]。

此外,Martini、Bosch 和 Chaudron [SP10] 指出,与新功能的实现相比,TD 重构计划的优先级通常较低,并且与新功能的实现没有直接关系的 TD 经常被推迟。

Vathsavayi 和 Systa [SP22] 赞同这一观点,指出“决定是否将资源用于开发新功能或修复债务是一项具有挑战性的任务”。 研究人员强调,软件团队需要在同一优先级流程中优先考虑新功能、错误修复和 TD 重构。

然而,即使实现新功能和 TD 重构活动之间的平衡被描述为重要的 [SP31],本研究中研究的论文通常将他们的优先级方法集中在不同 TD 项目之间的优先级上,目标是确定哪个项目应该先重构。 所调查的出版物中描述的优先级方法都没有明确说明应该如何在实现新功能和花费时间和精力重构 TD 之间进行优先级排序。然而,Besker 等人的研究。 (2019) 指出,“交付客户价值和满足交付期限的压力迫使软件团队不断降低 TD 重构的优先级,以快速实施新功能”。

5.3 RQ1.2 优先级是基于一次性活动还是基于连续过程?

与在项目中确定 TD 重构活动的优先级一样重要的是描述优先级流程的管理策略。

因此,本研究问题的重点是在审查的出版物中如何根据其周期性来描述优先化过程。 我们根据一次性活动与连续过程的一部分来区分不同的方法。

本研究中审查的一些出版物强调了 TD 优先排序过程,因为它是一个连续、集成和迭代的过程 [SP16],[SP22],而其他出版物则强调在每个 sprint [SP15] 中优先考虑 TD 重构的重要性。 乔杜里等人。 [SP19] 通过说“理想情况下,软件公司试图将重构实践作为其开发和维护过程的一个组成部分”[SP9] 和 [SP39] 来说明优先级确定过程是持续开发过程的一个组成部分 这个概念表明“在开发项目的每个版本中,对 TD 的系统管理以及如何减少它也应该被认为是重要的”。

然而,有趣的是,本研究中审查的其他出版物并未就应多久或以何种方式对 TD 进行优先排序给出任何明确的建议。

5.4 RQ2 TD优先级考虑了哪些因素和措施?

当我们分析论文以了解哪些因素用于 TD 优先排序时,我们使用了自下而上的方法(归纳分析)。 通过演绎分析(预先确定先验类别),我们可能会错过一些因素。

首先,我们用提到的因素对每篇论文进行编码,并获得了一长串<因素,论文>。 然后我们对重叠的因子进行分组重命名,得到<factor, (paper1, paper2, ...)>的列表。 最后,我们根据软件开发的不同方面对因素进行了分类。这个过程的结果,特别是与兴趣相关的因素,在表 7 中可见。

在确定优先级的过程中,6 个 PS 考虑了本金和兴趣([SP1]、[SP10]、[SP13]、[SP15]、[SP23]、[SP35]),而 4 个 PS 只考虑了兴趣([SP13] 、[SP17]、[SP27]、[SP34])。

本金计算为修复技术质量问题 [SP1] 或违反质量规则 [SP13] 所需的成本 [SP1]、[SP10] 或时间 [SP1]、[SP4]。 还考虑了其​​他因素,例如页面排名或客户反馈 [SP23]。

利息计算为由于技术质量问题 [SP1]、[SP10]、[SP17]、[SP35] 或与不同活动(管理或重构)相关的浪费时间 [SP27]、[SP34] 导致的额外维护成本 ]。 将本金与利息进行比较,而不考虑任何收益不超过成本的项目[SP15]。 考虑的因素是:客户期望,这是最优先的,其次是开发资源的可用性,TD项目的兴趣,受债务影响的模块的当前状态,以及债务对其他功能的影响[ SP15]。

在表 7 中,我们展示了一个“影响图”,它突出了与 TD 的影响(兴趣)相关的大量因素,这些因素需要考虑优先级,以及它们在研究和项目中的广泛差异。 我们总共计算了 53 个独特的因素。

 一些因素可能重叠,尽管在不同的论文中这些因素的计算方式不同。 例如,“错误数量”和“投资回报率(根据错误数量计算)”显然是重叠的因素,尽管在确定优先级时使用错误的绝对数量或其影响的成本作为指标可能会给出非常不同的结果 . 在其他情况下,使用了“利息”或“成本”的通用概念,尽管这些值可能是研究人员或从业人员考虑到其他 52 个剩余因素中的一些在其他情况下明确提到的隐含计算出来的。 文件。 但是,鉴于报告的信息,没有办法执行这样的映射。因此,我们报告了一个与所有其他特定因素不同的通用因素,例如“风险”。

在可能的情况下,这些因素已被分类,以帮助导航它们。 首先,我们将因素映射到质量与TD相关的最常提及的内容。 这些类别是“进化”、“维护”和“生产力”。 例如,TD 的当前工作定义明确提到了对可维护性和可演化性的影响。 鉴于对这些品质的重视,我们首先根据它们对因素进行分组。 影响其他品质的 TD 被收集在“系统品质”下(不包括前两者)。 生产力通常也与 TD 相关联,其形式为因债务而付出的额外努力。

接下来,我们继续根据影响相关的软件开发方面对剩余因素进行分类和分组。 这对于了解哪些角色会受到这种影响的影响最大以及它可能对优先级产生什么影响非常重要。 举个例子,TD 可以对“客户”因素产生直接影响,因此某些组织可能会认为此类 TD 在其优先级排序中更为重要。 了解对“业务”因素的影响对于针对主要使用业务问题进行优先级排序的功能进行优先级排序也非常有用。 作为软件开发的非技术方面,还需要考虑“社会”和“项目”因素。

对于某些因素,无法找到一个共同的类别(“其他因素”),或者仅将它们描述为没有附加细节的高级因素(“未指定”)。

大多数论文关注 TD 对主要可维护性的影响 (12)。 一些论文关注生产力 (7)、可进化性 (5) 和其他系统质量 (6),而五篇论文则考虑了客户的观点。

只有少数论文考虑了其他因素,如商业因素(3)、社会因素(3)、项目因素(3)和其他非分类因素(6)。 在大多数情况下(包括客户方面),已确定的因素已在一两篇论文中报告。 这突出了它们对特定背景的特异性或文献中缺乏对这些因素的关注。 在 [SP10] 和 [SP24] 中,作者对从业者进行了一项调查,以了解哪些因素对开发人员、架构师和产品所有者最重要。 在大多数情况下,客户和业务因素被认为是最重要的因素。 然而,在优先考虑 TD 时,只有少数论文解决了这些因素,因此我们可以得出结论,这些因素在文献中被忽略了。

在相当多的研究中 (8),TD 的兴趣(影响)已被确定并评估为一般兴趣、兴趣可能性、风险、严重性,或由从业者定制。 六篇论文介绍了未在前面提到的类别中具体分类的因素,它们代表了跨多个类别的 TD 的影响或代表与这些类别无关的特定方面。

其他 8 篇论文假设 TD 的影响与被认为是次优的不同问题(例如,代码异味)实例的(共同)发生有关(表中的“债务数量”)。 但是,不同论文中使用的措施根据所使用的工具而有所不同,并且各个问题的影响被假设为相同或被任意分配。与 TD 的影响(兴趣)相比,很少有论文 (4) 使用重构成本(主要)的估计或度量。这与理论方法(Chatzigeorgiou et al., 2015; Martini and Bosch, 2016b, [SP8])形成对比,理论方法需要通过考虑重构成本和影响来优先考虑 TD。

5.3 RQ3哪些工具已被用于TD优先化

如表 8 所示,只有 14 篇论文提到了使用工具来评估和优先处理 TD,但其中只有 10 篇报告了使用哪些工具的信息。 其他研究使用了为其特定目的开发的定制工具。

 在上述工具中,我们可以识别出十个静态分析工具:ARCAN、CAST、Coverity、Findbugs、Visual Studio Fx CopAnalyzer、iPlasma、Jspirit、Scitool Understanding 和 SonarQube。

Scitool Understanding 分析代码并可视化其架构。 其余的检测 TD 问题,例如代码或架构异味、安全违规或其他问题。 CAST、Coverity、Findbugs、Studio FxCopAnalyzer、Codescene 和 SonarQube 是通常用于根据一组规则分析代码合规性的商业工具。 当违反规则时,它们会引发 TD 问题。 这些工具提供问题的严重性并将它们分类为不同的类型(例如,可能导致错误、增加软件维护工作或安全漏洞的问题)。 此外,CAST 和 SonarQube 还关联了图 5。按年份划分的论文分布。补救工作(主要),消除 TD 问题所需的时间。 ARCAN、iPlasma 和 Jspirit 是开源工具,由研究团队开发,旨在检测架构异味 (ARCAN) 和代码异味(iPlasma 和 Jspirit)。

AnaConDebt (Martini, 2018) 是一种基于 TD 增强积压的管理工具。 待办事项允许创建 TD 项目并对创建的项目执行 TD 特定的操作。

在 [SP32] 和 [SP33] 中,AnaConDebt 已用于报告和可视化产品经理和开发人员手动收集的关于 TD 的信息。

CAFFEA 框架(Martini 和 Bosch,2016a)确定了分配架构职责的组织角色。 此外,该工具定义了团队成员并在他们之间共享。 该框架已在 [SP31] 中用于分析架构社区与系统架构之间的不匹配。

ARCAN 在 [SP38] 中用于检测建筑气味。 TD负责人随后通过在一家大公司进行的调查进行了调查。

在 [SP30] 中,开发人员被要求讨论 SonarQube 提出的 TD 问题。 但是,没有关于开发人员是否考虑了 TD 问题的严重性或类型的信息。 在 [SP4] 中,作者按原样使用 CAST 来估计按时间计算的本金,以消除所有 TD 问题。

iPlasma 和 Jspirit 分别在 [SP5] 和 [SP18] 中使用,以检测在调查的系统中要重构的代码异味的数量。

在 [SP21] 中使用 Scitool Understanding 来识别正在调查的系统中的架构问题。

Coverity、Findbugs 和 Visual Studio FxCopAnalyser 检测到的 TD 问题在 [SP20] 中用于工业调查。

6 讨论

在本节中,我们将讨论获得的结果,概述在 TD 领域工作的研究人员和从业者的一些影响。 尽管与软件测试或软件质量等其他领域相比,TD 领域相对年轻,但在过去十年中已经发表了重大贡献,研究人员变得越来越活跃(图 5)。

在 Li 等人 2015 年提出的十种 TD 类型中。 (2015 年)(表 1),在 TD 优先级的背景下,研究人员(RQ1)经常考虑仅代码债务和建筑债务。 在李等人提出的研究中。 (2015),代码债务是最常调查的 TD 类型,其次是测试债务。 然而,其他类型的 TD 也受到了极大的关注。 与李等人不同。 (2015),在我们的工作中发现,在考虑 TD 优先级时,代码债务和建筑债务是迄今为止最常被调查的债务类型。 这可能是因为它们易于测量,主要基于对其他领域的先前研究的扩展,或者也可能是因为它们(尤其是 ATD)被认为是最有害和最昂贵的 在软件中管理的类型。 例如,架构和代码模式已经研究了 20 多年,尽管它们不被视为“债务”。

两种最常考虑的 TD 类型(代码债务和架构债务)主要通过架构或代码级反模式(架构异味、代码异味或代码违规)进行评估。 此外,它们的危害性主要与它们对某些外部质量的影响有关(例如,特定代码气味对维护工作的影响)。然而,它们的影响仍不清楚,因为绝大多数研究不同意它们的危害性。 其他类型的 TD 应在未来进行调查。 我们认为代码债务是最常调查的类型,因为通过挖掘软件存储库研究很容易访问数据,而其他类型的债务需要其他类型的研究,包括涉及开发人员的案例研究。 我们建议从业者应该考虑本 RQ 中确定的措施,但应该用专家判断来补充它们,以了解要考虑哪些架构异味、代码异味或代码违规。

在受 TD 影响的软件中,减少此 TD 的唯一显着有效的方法是对其进行重构。 这一事实强调了持续和迭代地对已识别的重构任务进行优先级排序的重要性,从而突出了使用适当的 TD 优先级排序过程的重要性。 通过这项研究,我们确定了几种不同的方法和策略来确定 TD 的优先级(RQ1、RQ1.1 和 RQ1.2)。 但是,该活动没有统一的方法,也没有就在执行 TD 优先级流程时应关注哪些方面达成共识。

从研究结果中可以清楚地看出,TD 重构的优先级排序过程可以使用不同的方法进行,它们都有不同的目标,并针对不同的标准提出优化建议。

本研究确定了五种不同的主要方法,旨在:(a) 提高软件质量,尤其是可维护性和可演化性,(b) 提高​​软件从业者的生产力,(c) 降低软件的故障倾向,(d) 使用成本效益分析 (CBA) 比较各种 TD 项目以了解重构的便利性,以及 (e) 结合几种不同的方法。

这一结果对学术界和从业者都很有价值,并说明首先确定 TD 优先级的目标,然后针对已确定和指定的目标实施相应的 TD 优先级方法是很重要的。

一个有趣的发现是,被调查的论文通常只在优先级排序过程中比较不同的 TD 项目,而很少将实现新功能的需求与 TD 的重构进行比较。

关于在优先排序过程 (RQ2) 中考虑的特征和措施,迄今为止的结果表明,对 TD 进行优先排序是一项需要综合考虑多个因素的活动。 TD 的系统评估需要大量信息,这些信息可能会因情况而异,并且在大多数情况下,TD 是优先考虑的,没有遵循标准化的方法。 此外,一些论文中使用的已知度量仅捕获了用于确定 TD 优先级(维护成本或生产力的代理)的一小部分因素。 仅使用这些措施来确定 TD 的优先级,而不考虑相关因素(风险和成本)的全貌,可能会导致部分优先级,从而导致优先级有偏差,进而可能导致糟糕的业务决策。 另一方面,一些因素已在特定背景下进行的单一研究中报告,可能与其他优先级案例无关。

需要更多的研究来获得关于被忽视的因素(例如与客户、业务、社会和项目方面相关的因素)的更好证据。 此外,我们需要更好地了解在不同情况下应考虑哪些因素,以及在优先考虑 TD 时应考虑哪些额外措施。 最后,尽管已经报道了一些整体方法(Martini 和 Bosch,2016b,[SP24],[SP33]),但仍需要更好定义的框架和标准化的方法来评估 TD。

考虑到TD的两个主要组成部分,只有少数论文提出了如何评估本金和利息。利息主要计算为额外成本,或浪费在解决 TD 问题上的时间。 原因可能是,如果没有来自公司的经验数据,TD 利息就不容易计算。研究人员应设计和进行研究,以了解现有 TD 问题的实际兴趣。

对优先级活动的工具支持非常分散(RQ3),这突出表明缺乏专门用于 TD 优先级的可靠、广泛使用和经过验证的工具集。 当前的工具主要识别 TD 问题,并且在某些情况下,会提出修复这些问题所需时间的估计。 然而,据我们所知,没有工具可以计算由于活动推迟而产生的利息。

对从业者和研究人员的启示

这项工作突出了对研究人员和从业人员的一些启示,指出了需要更深入研究的有趣主题。 理解为什么研究人员主要关注代码和架构 TD,而不考虑 TD 似乎也相关且值得研究的其他类型的 TD(例如测试或基础设施 TD)可能是相关的。 此外,如果原因是由于缺乏素数领域的知识(例如方法或方法)、有限的数据或由于学术界的低水平兴趣,理解它可能是有用的。 研究人员还可以评估其他重要因素,例如不同的方法、影响变量和不同类型 TD 的优先级。 此外,研究人员不仅应该调查不同 TD 项目的优先级,还应该考虑在开发过程中重构 TD 的效果(例如在代码中添加新功能)以及重构代码所花费的时间和精力。 道明。 从业者可能会真正从这些调查中受益,并可能从开发过程的开始就避免或减少 TD 的积累。

此外,就如何计算 TD 的利息达成共识也很重要。 公司可以估计解决特定问题的努力(主要)(代码气味或代码样式违规),但他们无法估计延迟修复问题的影响和额外成本。

推迟修复活动也可能产生连锁反应,例如影响系统的其他部分。 例如,推迟软件库的采用可能会导致开发人员编写在最终采用该库时可能不需要的额外代码。 缺乏关于如何计算TD利息的知识可能会导致成本增加和软件开发质量下降等戏剧性影响,这可能会对客户产生负面影响。 计算 TD 兴趣的明确方法可以让公司根据偏好安排重构活动,并避免未来可能变得无法管理的 TD 积累。 为了解决这个问题,研究人员需要经验数据。 在这种情况下,从业者可以通过积极参与实证研究来发挥关键作用,提供研究人员缺失的数据。

研究人员还应将注意力集中在可能导致 TD 的其他因素上。 技术方面不是唯一应该考虑的方面。 与客户、商业和社会相关的因素研究较少,但可能提供另一个有趣的前景,并可能开辟一个跨学科的研究方向。

由于可用的工具还没有完全成熟,研究活动可以集中在现有工具的经验验证上,确认每个工具提出的每个措施的有用性。 从业者可以通过使用我们的影响图来探索/预测由于 TD 可能会产生什么样的影响,从而从我们的结果中受益。 此外,他们在选择工具时要谨慎,不能只使用一种,而要考虑不止一种。

7 有效性威胁

SLR 的结果可能会受到有效性威胁,主要涉及调查的正确性和完整性。 在本节中,我们将概述对在 TD 领域工作的研究人员和从业者的一些启示。 我们按照 Wohlin 等人的建议构建了本节。 (2012),包括结构、内部、外部和结论有效性威胁。

7.1 结构有效性

结构效度与将结果推广到研究执行背后的概念或理论有关(Wohlin 等,2012)。 在我们的案例中,它与所选研究的潜在主观分析有关。 根据 Kitchenham 指南(Kitchenham 和 Charters,2007 年)的建议,数据提取由两名或多名研究人员独立进行,如果出现差异,第三位作者参与讨论以消除任何分歧。 此外,根据 Dybå 和 Dingsøyr (2008) 提出的协议检查每篇选定论文的质量。

7.2 内部有效性

内部有效性威胁与关于治疗和结果之间因果关系的可能错误结论有关(Wohlin 等,2012)。 在二次研究的情况下,内部效度代表研究结果与文献中报道的结果的相似程度。 为了应对这些威胁,我们仔细遵循了 Kitchenham 和 Charters (2007) 提出的策略。

7.3 外部有效性

外部有效性威胁与概括结果的能力有关(Wohlin 等,2012)。 在二级研究中,外部效度取决于所选研究的效度。 如果所选研究在外部无效,则其内容的综合也将无效。 在我们的工作中,我们无法评估所有纳入研究的外部有效性。

7.4 结论有效性

结论效度与从结果中得出的结论的可靠性有关(Wohlin et al., 2012)。 在我们的案例中,威胁与某些研究的潜在不包含有关。 为了减轻这种威胁,我们仔细应用了搜索策略,结合滚雪球过程(Wohlin,2014)在八个数字图书馆中执行搜索,考虑检索到的论文中提供的所有参考文献,并评估所有论文 引用了检索到的那些,从而产生了另一篇相关论文。 我们应用了一个广泛的搜索字符串,这导致了大量的文章,但使我们能够包含更多可能的结果。 我们定义了纳入和排除标准,并首先将它们应用于标题和摘要。但是,我们并不完全依赖标题和摘要来确定该工作是否报告了有关技术债务优先级的证据。 在接受基于标题和摘要的论文之前,我们浏览了全文,再次应用我们的纳入。

8 结论

软件公司需要管理和重构 TD 问题,因为有时它们的存在是不可避免的,原因可能与组织内部或外部不可预测的业务或环境力量有关。 此外,某些类型的 TD 可能比其他类型更危险。 因此,有必要了解什么时候重构 TD 应该优先考虑实现功能或修复错误,或者相对于其他类型的 TD。

我们进行了 SLR 以调查软件工程中现有的知识体系,并了解软件组织中 TD 如何优先考虑以及提出了哪些研究方法。 SLR过程是通过以下两种严格的方法进行的。 我们收录了由最重要的书目来源索引并通过严格流程选择的科学文章。 我们考虑了 2019 年 12 月之前发表的文章。我们的工作基于 38 项选定的研究,其中包括有关在实践中使用或在研究中建议优先考虑 TD 的方法、因素、措施和工具的最新数据。

我们的审查结果表明,在考虑 TD 优先级时,代码债务和架构债务是迄今为止调查最多的债务类型,而关于其他类型的 TD,如测试债务和需求债务的证据很少。 TD 重构的优先级排序过程可以使用不同的方法进行,它们都有不同的目标并针对不同的标准提出优化建议。 然而,在一些论文中使用的确定的措施只捕获了用于确定 TD 优先级的一小部分因素。

缺乏衡量本金和利息的经验证据。 此外,我们的结果强调了缺乏专门用于 TD 优先级的可靠、经过验证和广泛使用的工具集。

在实践中,我们发现在优先考虑 TD 时需要考虑很多方面。 我们提出了一个这些因素的影响图,可以作为一个综合参考,了解一个组织可能支付的利息以及应该如何考虑。 这张地图也可以用来跟进进一步的研究。

未来的工作应侧重于研究较少调查的 TD 类型。 此外,我们正计划研究如何系统地评估和衡量不同类型TD的本金和利息。 我们还旨在开发一个框架,以支持与 TD 优先级相关的决策

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值