当前位置: X-MOL 学术Int. J. Softw. Eng. Knowl. Eng. › 论文详情
Our official English website, www.x-mol.net, welcomes your feedback! (Note: you will need to create a separate account there.)
The Technical Debt Density Over Multiple Releases and the Refactoring Story
International Journal of Software Engineering and Knowledge Engineering ( IF 0.9 ) Pub Date : 2021-02-07 , DOI: 10.1142/s0218194021500017
Mrwan BenIdris 1 , Hany Ammar 1 , Dale Dzielski 1
Affiliation  

Do developers postpone fixing Technical Debt (TD) in software systems? TD is a metaphor that refers to short-term decisions in software development that may affect the cost of the software development life cycle. The bad smell is an imperfect solution in the software system that negatively impacts the internal software quality and maintainability. In this paper, we will study five open-source software projects (OSSPs) that have several releases and also estimate the numbers of architecture smells (ASs), design smells (DSs), and code smells (CSs) for every release. Designite will be used to detect smells. We describe a case study conducted to explore the following: (1) What is the average smells density for architecture, design, and code smells in an OSSP? (2) Does the density of each smell type increase over multiple releases? (3) What percentage of each smell-type density is eliminated by refactoring? We collected around 2 million LOC from five OSSPs that have multiple releases from the GitHub repository to statistically analyze the software concerning the smells as indicators of TD. We find 36% of Architecture Technical Debt (ATD) is Cyclic Dependency, while 33% of Design Debt (DD) is Cyclically-dependent Modularization. More than 70% of Code Debt (CD) is Magic Number. Even though the developers do refactoring between releases, the TD density in general increases. On average, by refactoring, developers remove around 48%, 16%, and 22% from the introduced ATD, DD, and CD from their next release, respectively.

中文翻译:

多个版本的技术债务密度和重构故事

开发人员是否推迟修复软件系统中的技术债务 (TD)?TD是一个比喻,指的是软件开发中可能影响软件开发生命周期成本的短期决策。难闻的气味是软件系统中不完美的解决方案,会对内部软件质量和可维护性产生负面影响。在本文中,我们将研究五个具有多个版本的开源软件项目 (OSSP),并估计每个版本的架构异味 (AS)、设计异味 (DS) 和代码异味 (CS) 的数量。Designite 将用于检测气味。我们描述了一个案例研究,旨在探索以下内容:(1)建筑、设计、和 OSSP 中的代码气味?(2) 每种气味类型的密度是否会随着多次释放而增加?(3) 通过重构消除了每种气味类型密度的百分比是多少?我们从 GitHub 存储库中有多个版本的五个 OSSP 收集了大约 200 万个 LOC,以统计分析将气味作为 TD 指标的软件。我们发现 36% 的架构技术债务 (ATD) 是循环依赖,而 33% 的设计债务 (DD) 是循环依赖模块化。超过 70% 的代码债务 (CD) 是幻数。即使开发人员在发布之间进行重构,TD 密度通常也会增加。平均而言,通过重构,开发人员在下一个版本中分别从引入的 ATD、DD 和 CD 中删除了大约 48%、16% 和 22%。
更新日期:2021-02-07
down
wechat
bug