Relating Complexity, Explicitness, Effectiveness of Refactorings and Non-Functional Requirements: A Replication Study

• URL: http://arxiv.org/abs/2505.08016v1
• Date: Mon, 12 May 2025 19:26:33 GMT
• Title: Relating Complexity, Explicitness, Effectiveness of Refactorings and Non-Functional Requirements: A Replication Study
• Authors: Vinícius Soares, Lawrence Arkoh, Paulo Roberto Farah, Anderson Uchôa, Alessandro Garcia, Wesley K. G. Assunção,
• Abstract summary: Self-affirmed (SAR) is where developers explicitly state their intent to simplify requirements.<n>This study expanded the scope of Soares et al.'s study by doubling the number of projects and a significantly larger set of validated instances.<n>We observed that when developers explicitly state their intent, the resulting changes typically involve a combination of different types, making them more complex.
• Score: 39.82126443893643
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Refactoring is a practice widely adopted during software maintenance and evolution. Due to its importance, there is extensive work on the effectiveness of refactoring in achieving code quality. However, developer's intentions are usually overlooked. A more recent area of study involves the concept of self-affirmed refactoring (SAR), where developers explicitly state their intent to refactor. While studies on SAR have made valuable contributions, they provide little insights into refactoring complexity and effectiveness, as well as the refactorings' relations to specific non-functional requirements. A study by Soares et al. addressed such aspects, but it relied on a quite small sample of studied subject systems and refactoring instances. Following the empirical method of replication, we expanded the scope of Soares et al.'s study by doubling the number of projects analyzed and a significantly larger set of validated refactorings (8,408). Our findings only partially align with the original study. We observed that when developers explicitly state their refactoring intent, the resulting changes typically involve a combination of different refactoring types, making them more complex. Additionally, we confirmed that such complex refactorings positively impact code's internal quality attributes. While refactorings aimed at non-functional requirements tend to improve code quality, our findings only partially align with the original study and contradict it in several ways. Notably, SARs often result in fewer negative impacts on internal quality attributes despite their frequent complexity. These insights suggest the importance of simplifying refactorings where possible and explicitly stating their goals, as clear intent helps shape more effective and targeted refactoring strategies.

Related papers

• Refactoring $\ eq$ Bug-Inducing: Improving Defect Prediction with Code Change Tactics Analysis [54.361900378970134]
  Just-in-time defect prediction (JIT-DP) aims to predict the likelihood of code changes resulting in software defects at an early stage.<n>Prior research has largely ignored code during both the evaluation and methodology phases, despite its prevalence.<n>We propose Code chAnge Tactics (CAT) analysis to categorize code and its propagation, which improves labeling accuracy in the JIT-Defects4J dataset by 13.7%.
  arXiv  Detail & Related papers  (2025-07-25T23:29:25Z)
• Assessing the Bug-Proneness of Refactored Code: A Longitudinal Multi-Project Study [43.65862440745159]
  Refactoring is a common practice in software development, aimed at improving the internal code structure in order to make it easier to understand and modify.<n>It is often assumed that makes the code less prone to bugs.<n>However, in practice, is a complex task and applied in different ways. Therefore, certains can inadvertently make the code more prone to bugs.
  arXiv  Detail & Related papers  (2025-05-12T19:12:30Z)
• Automated Refactoring of Non-Idiomatic Python Code: A Differentiated Replication with LLMs [54.309127753635366]
  We present the results of a replication study in which we investigate GPT-4 effectiveness in recommending and suggesting idiomatic actions.<n>Our findings underscore the potential of LLMs to achieve tasks where, in the past, implementing recommenders based on complex code analyses was required.
  arXiv  Detail & Related papers  (2025-01-28T15:41:54Z)
• Insights into Deep Learning Refactoring: Bridging the Gap Between Practices and Expectations [13.084553746852382]
  Deep learning software has become progressively complex as the software evolves. The insight of code in the context of deep learning is still unclear. Research and the development of related tools are crucial for improving project maintainability and code quality.
  arXiv  Detail & Related papers  (2024-05-08T07:35:14Z)
• Automating Source Code Refactoring in the Classroom [15.194527511076725]
  This paper discusses the results of an experiment in the that involved carrying out various classroom activities for the purpose of removing antipatterns using Jodorant, an Eclipse plugin that supports antipatterns detection and correction. The results of the quantitative and qualitative analysis with 171 students show that students tend to appreciate the idea of learning, and are satisfied with various aspects of the JDeodorant plugin's operation.
  arXiv  Detail & Related papers  (2023-11-05T18:46:00Z)
• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection [74.51523859064802]
  We introduce a new framework called Self-Reflective Retrieval-Augmented Generation (Self-RAG) Self-RAG enhances an LM's quality and factuality through retrieval and self-reflection. It significantly outperforms state-of-the-art LLMs and retrieval-augmented models on a diverse set of tasks.
  arXiv  Detail & Related papers  (2023-10-17T18:18:32Z)
• State of Refactoring Adoption: Better Understanding Developer Perception of Refactoring [5.516979718589074]
  We aim to explore how developers document their activities during the software life cycle. We call such activity Self-Affirmed Refactoring (SAR), which indicates developers' documentation of their activities. We propose an approach to identify whether a commit describes developer-related events to classify them according to the common quality improvement categories.
  arXiv  Detail & Related papers  (2023-06-09T16:38:20Z)
• RefBERT: A Two-Stage Pre-trained Framework for Automatic Rename Refactoring [57.8069006460087]
  We study automatic rename on variable names, which is considered more challenging than other rename activities. We propose RefBERT, a two-stage pre-trained framework for rename on variable names. We show that the generated variable names of RefBERT are more accurate and meaningful than those produced by the existing method.
  arXiv  Detail & Related papers  (2023-05-28T12:29:39Z)
• Do code refactorings influence the merge effort? [80.1936417993664]
  Multiple contributors frequently change the source code in parallel to implement new features, fix bugs, existing code, and make other changes. These simultaneous changes need to be merged into the same version of the source code. Studies show that 10 to 20 percent of all merge attempts result in conflicts, which require the manual developer's intervention to complete the process.
  arXiv  Detail & Related papers  (2023-05-10T13:24:59Z)
• How We Refactor and How We Document it? On the Use of Supervised Machine Learning Algorithms to Classify Refactoring Documentation [25.626914797750487]
  Refactoring is the art of improving the design of a system without altering its external behavior. This study categorizes commits into 3 categories, namely, Internal QA, External QA, and Code Smell Resolution, along with the traditional BugFix and Functional categories. To better understand our classification results, we analyzed commit messages to extract patterns that developers regularly use to describe their smells.
  arXiv  Detail & Related papers  (2020-10-26T20:33:17Z)

This list is automatically generated from the titles and abstracts of the papers in this site.

This site does not guarantee the quality of this site (including all information) and is not responsible for any consequences.