Characterizing and Identifying Composite Refactorings

Sousa, Leonardo; Cedrim, Diego; Garcia, Alessandro; Oizumi, Willian; Bibiano, Ana Carla; Oliveira, Daniel; Kim, Miryung; Oliveira, Anderson

doi:10.1145/3379597.3387477

Cited by 31 publications

(140 citation statements)

References 44 publications

Supporting

Mentioning

138

Contrasting

Order By: Relevance

“…Kim et al [36] study refactoring challenges and benefits at Microsoft, while Vassallo et al [69] perform a large-scale refactoring study on open-source software, and Murphy-Hill et al [70] study general refactoring at the IDE level. Sousa et al [71] characterize composite refactorings, Hora and Robbes [72] explore the characteristics of method extraction refactorings, Peruma et al [73] investigate refactorings of unit tests in Android, and Bavota et al [60] and Ferreira et al [74] study fault inducing refactoring activities.…”

Section: Re L a T E D W O R Kmentioning

confidence: 99%

An Empirical Study of Refactorings and Technical Debt in Machine Learning Systems

Tang

Khatchadourian

Bagherzadeh

et al. 2021

2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE)

View full text Add to dashboard Cite

Machine Learning (ML), including Deep Learning (DL), systems, i.e., those with ML capabilities, are pervasive in today's data-driven society. Such systems are complex; they are comprised of ML models and many subsystems that support learning processes. As with other complex systems, ML systems are prone to classic technical debt issues, especially when such systems are long-lived, but they also exhibit debt specific to these systems. Unfortunately, there is a gap of knowledge in how ML systems actually evolve and are maintained. In this paper, we fill this gap by studying refactorings, i.e., source-to-source semanticspreserving program transformations, performed in real-world, open-source software, and the technical debt issues they alleviate. We analyzed 26 projects, consisting of 4.2 MLOC, along with 327 manually examined code patches. The results indicate that developers refactor these systems for a variety of reasons, both specific and tangential to ML, some refactorings correspond to established technical debt categories, while others do not, and code duplication is a major crosscutting theme that particularly involved ML configuration and model code, which was also the most refactored. We also introduce 14 and 7 new ML-specific refactorings and technical debt categories, respectively, and put forth several recommendations, best practices, and anti-patterns. The results can potentially assist practitioners, tool developers, and educators in facilitating long-term ML system usefulness.Index Terms-empirical studies, refactoring, machine learning systems, technical debt, software repository mining I. In t r o d u c t io nIn the big data era, Machine Learning (ML), including Deep Learning (DL), systems are pervasive in modern society. Central to these systems are dynamic ML models, whose behavior is ultimately defined by their input data. However, such systems do not only consist of ML models; instead, ML systems typically encompass complex subsystems that support ML processes [1]. ML systems-like other long-lived, complex systems-are prone to classic technical debt [2 ] issues; yet, they also exhibit debt specific to such systems [3]. While work exist on applying software engineering (SE) rigor to ML systems [4]- [12], there is generally a gap of knowledge in how ML systems actually evolve and are maintained. As ML systems become more difficult and expensive to maintain [1 ], understanding the kinds of modifications developers are required to make to such systems-our overarching research question-is of the utmost importance.To fill this gap, we performed an empirical study on common refactorings, i.e., source-to-source semantics preserving program transformations-a widely accepted mechanism for effectively reducing technical debt [13]-[16]-in real-world, open-source ML systems. We set out to discover (i) the kinds of refactorings-both specific and tangential to ML-performed, (ii) whether particular refactorings occurred more often in model code vs. other supporting subsystems, (iii) the types of technical debt ...

show abstract

Section: Re L a T E D W O R Kmentioning

confidence: 99%

An Empirical Study of Refactorings and Technical Debt in Machine Learning Systems

Tang

Khatchadourian

Bagherzadeh

et al. 2021

2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE)

View full text Add to dashboard Cite

show abstract

“…Thus, one could hypothesize that by combining multiple transformation types, developers can better address major structural problems in the code [8,34,50]. These combinations of transformations could be considered "complex refactorings".…”

Section: Nfc -Non-functional Concernmentioning

confidence: 99%

“…These composite refactorings can also be split into two groups, depending on which heuristic was used to detect them. Commit-based, which means that the composite was a group of refactorings applied within a single commit, or change, regardless of which methods/classes they were applied on; and range-based, which means that the composite was a group of refactorings applied over a series of commits, or changes, consecutively performed over the same small set of methods/classes [50].…”

Section: Refactoring and Its Mechanicsmentioning

confidence: 99%

“…Previous studies have analyzed many different factors in order to determine which of them could influence refactoring effectiveness. Their goal is to understand the common non-positive effect of refactorings [8,9,50]. However, these works mainly focused on analyzing how the mechanics of the applied refactorings affect such effectiveness, rather than how the refactoring-related concerns of the developers performing the code transformations could do so.…”

Section: On the Relation Between Complexity Explicitness Effectiveness Of Refactorings And Non-functional Concernsmentioning

confidence: 99%

“…Thus, their research has been growing in popularity in the last few years [8]. Along with this, recent studies also described the many kinds of composite refactoring patterns used in practice [50]. They range from a simple, repeated usage of one or two different types of refactorings, to complex processes spanning over 5 different types of refactorings [9].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Aligning Developer Quality Concerns, Refactoring Applications, and Their Effects

Soares¹

View full text Add to dashboard Cite

Minha pesquisa atual tem como foco determinar a correlação entre preocupações de desenvolvedores com relação à qualidade do código sendo modificado, e tanto quais quanto como refatorações são aplicadas ao código nestas situações. Assim, pretende-se permitir que desenvolvedores tenham uma maneira mais acurada de definir quais refatorações devem ser aplicadas, e como devem ser aplicadas, dependendo da situação atual, e das preocupações do desenvolvedor no momento da mudança. Como resultado de minha dedicação à pesquisa, enviei trabalhos aceitos para veículos relevantes, como o Simpósio Brasileiro de Engenharia de Software (SBES).

show abstract

Towards a catalog of composite refactorings

Brito

Hora

Valente

2023

J Software Evolu Process

View full text Add to dashboard Cite

Catalogs of refactoring have key importance in software maintenance and evolution, since developers rely on such documents to understand and perform refactoring operations. Furthermore, these catalogs constitute a reference guide for communication between practitioners since they standardize a common refactoring vocabulary. Fowler's book describes the most popular catalog of refactorings, which documents single and well‐known refactoring operations. However, sometimes, refactorings are composite transformations, that is, a sequence of refactorings is performed over a given program element. For example, a sequence of Extract Method operations (a single refactoring) can be performed over the same method, in one or in multiple commits, to simplify its implementation, therefore, leading to a Method Decomposition operation (a composite refactoring). In this paper, we propose and document a catalog with eight composite refactorings. We also implement a set of scripts to mine composite refactorings by preprocessing the results of refactoring detection tools. Using such scripts, we search for composites in a representative refactoring oracle with hundreds of confirmed single refactoring operations. Next, to complement this first study, we also search for composites in the full history of 10 well‐known open‐source projects. We characterize the detected composite refactorings, under dimensions such as size and location. We conclude by addressing the applications and implications of the proposed catalog.

show abstract

Characterizing and Identifying Composite Refactorings

Cited by 31 publications

References 44 publications

An Empirical Study of Refactorings and Technical Debt in Machine Learning Systems

An Empirical Study of Refactorings and Technical Debt in Machine Learning Systems

Aligning Developer Quality Concerns, Refactoring Applications, and Their Effects

Towards a catalog of composite refactorings

Contact Info

Product

Resources

About