31 research outputs found
State of Refactoring Adoption: Towards Better Understanding Developer Perception of Refactoring
Context: Refactoring is the art of improving the structural design of a software system without altering its external behavior. Today, refactoring has become a well-established and disciplined software engineering practice that has attracted a significant amount of research presuming that refactoring is primarily motivated by the need to improve system structures. However, recent studies have shown that developers may incorporate refactoring strategies in other development-related activities that go beyond improving the design especially with the emerging challenges in contemporary software engineering. Unfortunately, these studies are limited to developer interviews and a reduced set of projects. Objective: We aim at exploring how developers document their refactoring activities during the software life cycle. We call such activity Self-Affirmed Refactoring (SAR), which is an indication of the developer-related refactoring events in the commit messages. After that, we propose an approach to identify whether a commit describes developer-related refactoring events, to classify them according to the refactoring common quality improvement categories. To complement this goal, we aim to reveal insights into how reviewers develop a decision about accepting or rejecting a submitted refactoring request, what makes such review challenging, and how to the efficiency of refactoring code review. Method: Our empirically driven study follows a mixture of qualitative and quantitative methods. We text mine refactoring-related documentation, then we develop a refactoring taxonomy, and automatically classify a large set of commits containing refactoring activities, and identify, among the various quality models presented in the literature, the ones that are more in-line with the developer\u27s vision of quality optimization, when they explicitly mention that they are refactoring to improve them to obtain an enhanced understanding of the motivation behind refactoring. After that, we performed an industrial case study with professional developers at Xerox to study the motivations, documentation practices, challenges, verification, and implications of refactoring activities during code review. Result: We introduced SAR taxonomy on how developers document their refactoring strategies in commit messages and proposed a SAR model to automate the detection of refactoring. Our survey with code reviewers has revealed several difficulties related to understanding the refactoring intent and implications on the functional and non-functional aspects of the software. Conclusion: Our SAR taxonomy and model, can work in conjunction with refactoring detectors, to report any early inconsistency between refactoring types and their documentation and can serve as a solid background for various empirical investigations. In light of our findings of the industrial case study, we recommended a procedure to properly document refactoring activities, as part of our survey feedback
State of Refactoring Adoption: Better Understanding Developer Perception of Refactoring
We aim to explore how developers document their refactoring activities during
the software life cycle. We call such activity Self-Affirmed Refactoring (SAR),
which indicates developers' documentation of their refactoring activities. SAR
is crucial in understanding various aspects of refactoring, including the
motivation, procedure, and consequences of the performed code change. After
that, we propose an approach to identify whether a commit describes
developer-related refactoring events to classify them according to the
refactoring common quality improvement categories. To complement this goal, we
aim to reveal insights into how reviewers decide to accept or reject a
submitted refactoring request and what makes such a review challenging.Our SAR
taxonomy and model can work with refactoring detectors to report any early
inconsistency between refactoring types and their documentation. They can serve
as a solid background for various empirical investigations. Our survey with
code reviewers has revealed several difficulties related to understanding the
refactoring intent and implications on the functional and non-functional
aspects of the software. In light of our findings from the industrial case
study, we recommended a procedure to properly document refactoring activities,
as part of our survey feedback.Comment: arXiv admin note: text overlap with arXiv:2010.13890,
arXiv:2102.05201, arXiv:2009.0927
How We Refactor and How We Mine it ? A Large Scale Study on Refactoring Activities in Open Source Systems
Refactoring, as coined by William Obdyke in 1992, is the art of optimizing the syntactic design of a software system without altering its external behavior. Refactoring was also cataloged by Martin Fowler as a response to the existence of design defects that negatively impact the software\u27s design. Since then, the research in refactoring has been driven by improving systems structures. However, recent studies have been showing that developers may incorporate refactoring strategies in other development related activities that go beyond improving the design. In this context, we aim in better understanding the developer\u27s perception of refactoring by mining and automatically classifying refactoring activities in 1,706 open source Java projects. We perform a \textit{differentiated replication} of the pioneering work by Tsantalis et al. We revisit five research questions presented in this previous empirical study and compare our results to their original work. The original study investigates various types of refactorings applied to different source types (i.e., production vs. test), the degree to which experienced developers contribute to refactoring efforts, the chronological collocation of refactoring with the release and testing periods, and the developer\u27s intention behind specific types of refactorings. We reexamine the same questions but on a larger number of systems. To do this, our approach relies on mining refactoring instances executed throughout several releases of each project we studied. We also mined several properties related to these projects; namely their commits, contributors, issues, test files, etc. Our findings confirm some of the results of the previous study and we highlight some differences for discussion. We found that 1) feature addition and bug fixes are strong motivators for developers to refactor their code base, rather than the traditional design improvement motivation; 2) a variety of refactoring types are applied when refactoring both production and test code. 3) refactorings tend to be applied by experienced developers who have contributed a wide range of commits to the code. 4) there is a correlation between the type of refactoring activities taking place and whether the source code is undergoing a release or a test period
Can Refactoring be Self-Affirmed? An Exploratory Study on How Developers Document their Refactoring Activities in Commit Messages
Refactoring is a critical task in software maintenance and is usually performed to enforce best design practices, or to cope with design defects. Previous studies heavily rely on defining a set of keywords to identify refactoring commits from a list of general commits extracted from a small set of softwaresystems. All approaches thus far consider all commits without checking whether refactorings had actually happened or not. In this paper, we aim at exploring how developers document their refactoring activities during the software life cycle. We call such activity Self-Affirmed Refactoring, which is an indication ofthe developer-related refactoring events in the commit messages. Our approach relies on text mining refactoring-related change messages and identifying refactoring patterns by only consideringrefactoring commits. We found that (1) developers use a variety of patterns to purposefully target refactoring-related activities; (2) developers tend to explicitly mention the improvement of specific quality attributes and code smells; and (3) commit messages withself-affirmed refactoring patterns tend to have more significant refactoring activit
Toward the Automatic Classification of Self-Affirmed Refactoring
The concept of Self-Affirmed Refactoring (SAR) was introduced to explore how developers document their refactoring activities in commit messages, i.e., developers explicit documentation of refactoring operations intentionally introduced during a code change. In our previous study, we have manually identified refactoring patterns and defined three main common quality improvement categories including internal quality attributes, external quality attributes, and code smells, by only considering refactoring-related commits. However, this approach heavily depends on the manual inspection of commit messages. In this paper, we propose a two-step approach to first identify whether a commit describes developer-related refactoring events, then to classify it according to the refactoring common quality improvement categories. Specifically, we combine the N-Gram TF-IDF feature selection with binary and multiclass classifiers to build a new model to automate the classification of refactorings based on their quality improvement categories. We challenge our model using a total of 2,867 commit messages extracted from well engineered open-source Java projects. Our findings show that (1) our model is able to accurately classify SAR commits, outperforming the pattern-based and random classifier approaches, and allowing the discovery of 40 more relevent SAR patterns, and (2) our model reaches an F-measure of up to 90% even with a relatively small training datase
Mining and Managing Big Data Refactoring for Design Improvement: Are We There Yet?
Refactoring is a set of code changes applied to improve the internal structure of a program, without altering its external behavior. With the rise of continuous integration and the awareness of the necessity of managing technical debt, refactoring has become even more popular in recent software builds. Recent studies indicate that developers often perform refactorings. If we consider all refactorings performed across all projects, this consists of the refactoring knowledge that represents a rich source of information that can be useful for both developers and practitioners to better understand how refactoring is being applied in practice. However, mining, processing, and extracting useful insights, from this plethora of refactorings, seems to be challenging. In this book chapter, we take a dive into how refactoring can be mined and preprocessed. We discuss all design concepts and structural metrics that can also be mined along with refactoring operations to understand their impact better. We further investigate the many practical challenges for such extraction. The volume, velocity, and variety of extracted data require careful planning. We outline the appropriate techniques from a large number of available technologies for such system implementation
Automating Source Code Refactoring in the Classroom
Refactoring is the practice of improving software quality without altering
its external behavior. Developers intuitively refactor their code for multiple
purposes, such as improving program comprehension, reducing code complexity,
dealing with technical debt, and removing code smells. However, no prior
studies have exposed the students to an experience of the process of
antipatterns detection and refactoring correction, and provided students with
toolset to practice it. To understand and increase the awareness of refactoring
concepts, in this paper, we aim to reflect on our experience with teaching
refactoring and how it helps students become more aware of bad programming
practices and the importance of correcting them via refactoring. This paper
discusses the results of an experiment in the classroom that involved carrying
out various refactoring activities for the purpose of removing antipatterns
using JDeodorant, an Eclipse plugin that supports antipatterns detection and
refactoring. The results of the quantitative and qualitative analysis with 171
students show that students tend to appreciate the idea of learning refactoring
and are satisfied with various aspects of the JDeodorant plugin's operation.
Through this experiment, refactoring can turn into a vital part of the
computing educational plan. We envision our findings enabling educators to
support students with refactoring tools tuned towards safer and trustworthy
refactoring
On the Impact of Refactoring on the Relationship between Quality Attributes and Design Metrics
Refactoring is a critical task in software maintenance and is generally performed to enforce the best design and implementation practices or to cope with design defects. Several studies attempted to detect refactoring activities through mining software repositories allowing to collect, analyze and get actionable data-driven insights about refactoring practices within software projects. Aim: We aim at identifying, among the various quality models presented in the literature, the ones that are more in-line with the developer’s vision of quality optimization, when they explicitly mention that they are refactoring to improve them. Method: We extract a large corpus of design-related refactoring activities that are applied and documented by developers during their daily changes from 3,795 curated open source Java projects. In particular, we extract a large-scale corpus of structural metrics and anti-pattern enhancement changes, from which we identify 1,245 quality improvement commits with their corresponding refactoring operations, as perceived by software engineers. Thereafter, we empirically analyze the impact of these refactoring operations on a set of common state-of-the-art design quality metrics. Results: The statistical analysis of the obtained results shows that (i) a few state-of-the-art metrics are more popular than others; and (ii) some metrics are being more emphasized than others. Conclusions: We verify that there are a variety of structural metrics that can represent the internal quality attributes with different degrees of improvement and degradation of software quality. Most of the metrics that are mapped to the main quality attributes do capture developer intentions of quality improvement reported in the commit messages, but for some quality attributes, they don’t
On Preserving the Behavior in Software Refactoring: A Systematic Mapping Study
Context: Refactoring is the art of modifying the design of a system without
altering its behavior. The idea is to reorganize variables, classes and methods
to facilitate their future adaptations and comprehension. As the concept of
behavior preservation is fundamental for refactoring, several studies, using
formal verification, language transformation and dynamic analysis, have been
proposed to monitor the execution of refactoring operations and their impact on
the program semantics. However, there is no existing study that examines the
available behavior preservation strategies for each refactoring operation.
Objective: This paper identifies behavior preservation approaches in the
research literature.
Method: We conduct, in this paper, a systematic mapping study, to capture all
existing behavior preservation approaches that we classify based on several
criteria including their methodology, applicability, and their degree of
automation.
Results: The results indicate that several behavior preservation approaches
have been proposed in the literature. The approaches vary between using
formalisms and techniques, developing automatic refactoring safety tools, and
performing a manual analysis of the source code.
Conclusion: Our taxonomy reveals that there exist some types of refactoring
operations whose behavior preservation is under-researched. Our classification
also indicates that several possible strategies can be combined to better
detect any violation of the program semantics
Code Review Practices for Refactoring Changes: An Empirical Study on OpenStack
Modern code review is a widely used technique employed in both industrial and open-source projects to improve software quality, share knowledge, and ensure adherence to coding standards and guidelines. During code review, developers may discuss refactoring activities before merging code changes in the code base. To date, code review has been extensively studied to explore its general challenges, best practices and outcomes, and socio-technical aspects. However, little is known about how refactoring is being reviewed and what developers care about when they review refactored code. Hence, in this work, we present a quantitative and qualitative study to understand what are the main criteria developers rely on to develop a decision about accepting or rejecting a submitted refactored code, and what makes this process challenging. Through a case study of 11,010 refactoring and non-refactoring reviews spread across OpenStack open-source projects, we find that refactoring-related code reviews take significantly longer to be resolved in terms of code review efforts. Moreover, upon performing a thematic analysis on a significant sample of the refactoring code review discussions, we built a comprehensive taxonomy consisting of 28 refactoring review criteria. We envision our findings reaffirming the necessity of developing accurate and efficient tools and techniques that can assist developers in the review process in the presence of refactorings