Understanding, Analysis, and Handling of Software Architecture Erosion DOI Open Access
Ruiyin Li

Published: Nov. 21, 2023

Architecture erosion occurs when a software system's implemented architecture diverges from the intended over time. Studies show impacts development, maintenance, and evolution since it accumulates imperceptibly. Identifying early symptoms like architectural smells enables managing through refactoring. However, research lacks comprehensive understanding of erosion, unclear which are most common, detection methods. This thesis establishes an landscape, investigates symptoms, proposes identification approaches. A mapping study covers definitions, causes, consequences. Key findings: 1) "Architecture erosion" is used term, with four perspectives on definitions respective symptom types. 2) Technical non-technical reasons contribute to negatively impacting quality attributes. Practitioners can advocate addressing prevent failures. 3) Detection correction approaches categorized, consistency evolution-based commonly mentioned.An empirical explores practitioner communities, surveys, interviews. Findings reveal associated practices code review tools identify while collected measures address during implementation. Studying comments analyzes in practice. One reveals violations, duplicate functionality, cyclic dependencies frequent. Symptoms decreased time, indicating increased stability. Most were addressed after review. second violation projects, identifying 10 categories. Refactoring removing some disregarded.Machine learning classifiers using pre-trained word embeddings reviews. SVM word2vec achieved highest performance. fastText worked well. 200-dimensional outperformed 100/300-dimensional. 4) Ensemble classifier improved 5) found results valuable, confirming potential.An automated recommendation system identifies qualified reviewers for violations similarity file paths comments. Experiments common methods perform well, outperforming baseline approach. Sampling techniques impact

Language: Английский

Negativity in self-admitted technical debt: how sentiment influences prioritization DOI Creative Commons
Nathan Cassee, Neil A. Ernst, Nicole Novielli

et al.

Empirical Software Engineering, Journal Year: 2025, Volume and Issue: 30(2)

Published: Jan. 15, 2025

Abstract Self-Admitted Technical Debt, or SATD, is a self-admission of technical debt present in software system. The presence SATD systems negatively affects developers, therefore, managing and addressing crucial for engineering. To effectively manage developers need to estimate its priority assess the effort required fix described debt. About quarter descriptions express some form negativity negative emotions when describing In this paper, we report on an experiment conducted with 59 respondents study whether expressed description actually prioritization SATD. are mix professional students, experiment, asked participants prioritize four vignettes: two expressing neutral sentiment. ensure vignettes were realistic, they based existing extracted from dataset. We find that causes between one-third half which as having more priority. Developers affected by prioritizing twice likely increase their estimation urgency 1.5 times importance compared likelihood decreasing these scores. Our findings show how actively use determine urgently particular instance should be addressed. However, our also describes gap actions belief developers. Even if 33% 50% 67% believe using proxy unacceptable. Therefore, would not recommend recognize it might unavoidable describe

Language: Английский

Citations

0
Code review practices for refactoring changes DOI Open Access
Eman Abdullah AlOmar, Moataz Chouchen, Mohamed Wiem Mkaouer

et al.

Published: May 23, 2022

Modern code review is a widely used technique employed in both industrial and open-source projects to improve software quality, share knowledge, ensure adherence coding standards guidelines. During review, developers may discuss refactoring activities before merging changes the base. To date, has been extensively studied explore its general challenges, best practices outcomes, socio-technical aspects. However, little known about how being reviewed what care when they refactored code. Hence, this work, we present quantitative qualitative study understand are main criteria rely on develop decision accepting or rejecting submitted code, makes process challenging. Through case of 11,010 non-refactoring reviews spread across OpenStack projects, find that refactoring-related take significantly longer be resolved terms efforts. Moreover, upon performing thematic analysis significant sample discussions, built comprehensive taxonomy consisting 28 criteria. We envision our findings reaffirming necessity developing accurate efficient tools techniques can assist presence refactorings.

Language: Английский

Citations

16
Are Prompt Engineering and TODO Comments Friends or Foes? An Evaluation on GitHub Copilot DOI Creative Commons
David O'Brien, Sumon Biswas, Sayem Mohammad Imtiaz

et al.

Published: April 12, 2024

Code intelligence tools such as GitHub Copilot have begun to bridge the gap between natural language and programming language. A frequent software development task is management of technical debts, which are suboptimal solutions or unaddressed issues hinder future development. Developers been found "self-admit" debts (SATD) in artifacts source code comments. Thus, it possible that information present these comments can enhance generative prompts repay described SATD? Or, does inclusion instead cause reproduce harmful symptoms debt? Does modification SATD impact this reaction? Despite heavy maintenance costs caused by debt recent improvements tools, no prior works sought incorporate towards prompt engineering. Inspired this, paper contributes analyzes a dataset consisting 36,381 TODO latest available revisions their respective 102,424 repositories, from we sample manually generate 1,140 bodies using Copilot. Our experiments show with SATD, both prompted unprompted. Moreover, demonstrate tool's ability automatically under different circumstances qualitatively investigate characteristics successful unsuccessful Finally, discuss gaps Copilot's successors researchers improve upon tasks facilitate AI-assisted maintenance.

Language: Английский

Citations

3
Self-Admitted Technical Debt in Ethereum Smart Contracts: A Large-Scale Exploratory Study DOI

Amir M. Ebrahimi,

Gustavo A. Oliva, Ahmed E. Hassan

et al.

IEEE Transactions on Software Engineering, Journal Year: 2023, Volume and Issue: 49(9), P. 4304 - 4323

Published: June 27, 2023

Programmable blockchain platforms such as Ethereum offer unique benefits to application development, including a decentralized infrastructure, tamper-proof transactions, and auditability. These enable new types of applications that can bring competitive advantage several business segments. Nonetheless, the pressure time-to-market combined with relatively immature development technologies (e.g., Solidity programming language), lack high-quality training resources, an unclear roadmap for creates context favors introduction technical debt code hacks, workarounds, suboptimal implementations) into code. In this paper, we study self-admitted (SATD) in smart contracts. SATD refers is explicitly acknowledged source by developers via comments. We extract 726 k real-world contracts from apply both quantitative qualitative methods order (i) determine prevalence, (ii) understand relationship between cloning (iii) uncover different categories SATD. Our findings reveal that, while not widespread phenomenon (1.5% contain SATD), does occur extremely relevant multi-million contracts). also observed strong connection prevalence activities, leading us conclude former cannot be reliably studied without taking latter consideration. Finally, produced taxonomy consists 6 major 26 minor categories. note are bound domain contracts, gas-inefficient implementations Solidity-induced workarounds. Based on our results, derive set practical recommendations contract introduce open research questions guide future topic.

Language: Английский

Citations

4
On the documentation of self-admitted technical debt in issues DOI
Laerte Xavier, João Eduardo Montandon, Fábio Ferreira

et al.

Empirical Software Engineering, Journal Year: 2022, Volume and Issue: 27(7)

Published: Sept. 20, 2022

Language: Английский

Citations

7
What Can Self-Admitted Technical Debt Tell Us About Security? A Mixed-Methods Study DOI Creative Commons
Nicolás E. Díaz Ferreyra, Mojtaba Shahin,

Mansorreh Zahedi

et al.

arXiv (Cornell University), Journal Year: 2024, Volume and Issue: unknown

Published: Jan. 1, 2024

Self-Admitted Technical Debt (SATD) encompasses a wide array of sub-optimal design and implementation choices reported in software artefacts (e.g., code comments commit messages) by developers themselves. Such reports have been central to the study maintenance evolution over last decades. However, they can also be deemed as dreadful sources information on potentially exploitable vulnerabilities security flaws. This work investigates implications SATD from technical developer-centred perspective. On one hand, it analyses whether pointers disclosed inside used characterise Open-Source Software (OSS) projects repositories. other delves into developers' perspectives regarding motivations behind this practice, its prevalence, potential negative consequences. We followed mixed-methods approach consisting (i) analysis preexisting dataset containing 8,812 instances (ii) an online survey with 222 OSS practitioners. gathered 201 through mapped them different Common Weakness Enumeration (CWE) identifiers. Overall, 25 types CWEs were spotted across messages, pull requests, comments, issue sections, which 8 appear among MITRE's Top-25 most dangerous ones. The shows that practitioners often place promote culture their peers help spot flaky motives. consider such practice risky may facilitate vulnerability exploits. Our findings suggest preserving contextual integrity disseminated is critical safeguard both commercial solutions against zero-day attacks.

Language: Английский

Citations

1
Quantifying and characterizing clones of self-admitted technical debt in build systems DOI
Tao Xiao, Zhili Zeng, Dong Wang

et al.

Empirical Software Engineering, Journal Year: 2024, Volume and Issue: 29(2)

Published: Feb. 26, 2024

Language: Английский

Citations

1
Deciphering refactoring branch dynamics: An empirical study on Qt DOI
Eman Abdullah AlOmar

Information and Software Technology, Journal Year: 2024, Volume and Issue: 177, P. 107596 - 107596

Published: Oct. 5, 2024

Language: Английский

Citations

1
How social interactions can affect Modern Code Review DOI Creative Commons
Paolo Ciancarini,

Artem Kruglov,

Aygul Malikova

et al.

Frontiers in Computer Science, Journal Year: 2023, Volume and Issue: 5

Published: May 11, 2023

Introduction Modern Code Review (MCR) is a multistage process where developers evaluate source code written by others to enhance the software quality. Despite numerous studies conducted on effects of MCR quality, non-technical issues in have not been extensively studied. This study aims investigate social problems and find possible ways prevent them improve overall quality process. Methodology To achieve research objectives, we applied grounded theory shaped GQM approach collect data attitudes from different teams toward MCR. We interviews with 25 13 companies obtain information necessary how interactions affect reviewing Results Our findings show that interpersonal relationships within team can significant consequences also received list strategies overcome these problems. Discussion provides new perspective process, which has studied before. The this help development address their products. Conclusion valuable insights into them. Future could explore effectiveness identified addressing

Language: Английский

Citations

3
Warnings: Violation symptoms indicating architecture erosion DOI
Ruiyin Li, Peng Liang, Paris Avgeriou

et al.

Information and Software Technology, Journal Year: 2023, Volume and Issue: 164, P. 107319 - 107319

Published: Aug. 9, 2023

Language: Английский

Citations

3