Refactoring Graphs: Assessing Refactoring over Time

Abstract

Refactoring is an essential activity during software evolution. Frequently, practitioners rely on such transformations to improve source code maintainability and quality. As a consequence, this process may produce new source code entities or change the structure of existing ones. Sometimes, the transformations are atomic, i.e., performed in a single commit. In other cases, they generate sequences of modifications performed over time. To study and reason about refactorings over time, in this paper, we propose a novel concept called refactoring graphs and provide an algorithm to build such graphs. Then, we investigate the history of 10 popular open-source Java-based projects. After eliminating trivial graphs, we characterize a large sample of 1,150 refactoring graphs, providing quantitative data on their size, commits, age, refactoring composition, and developers. We conclude by discussing applications and implications of refactoring graphs, for example, to improve code comprehension, detect refactoring patterns, and support software evolution studies.

Towards a Catalog of Composite Refactorings

“…When used in a context like this one, a refactoring detection tool, such as RefDiff or RefactoringMiner [5][6][7][8][9][10], detects the six single refactorings independently. However, it would also be interesting to detect a high-level Techniques that may benefit from the detection of independent refactorings (like code visualization [12][13][14], code review [15][16][17][18][19], code authorship [20,21], bug-introducing detection [22,23], refactoring-aware tools [24,25], software mining approaches [26][27][28][29], to name a few) may also benefit from the detection of composite refactorings. As refactoring detection is the basis for such techniques, composite refactorings would bring to light novel operations not restricted to time and scope, therefore, better representing the actual source code changes.…”

“…We also detected Pull Up Method in this category. In the commit description, the developer also mention simplification of inheritance hierarchy: 14 "Create common [name class] base class... that will log why a condition has or has not been applied. This removes the need for [class name] and simplifies many of the existing condition implementations."…”

“…Regarding sequences of refactoring operations, there are graph-based visualizations [14,35], aiming to reason about refactoring performed over time at the method level. There is also the concept of batch refactorings, which were first defined by Murphy-Hill et al [44].…”

Identification and Refactoring of Design Problems in Software Systems

“…In this work, we call such refactoring sequences as composite refactorings. Despite composites being widely investigated in the literature (e.g., (Brito, Hora and Valente 2020), , (Bibiano et al 2019), and (Sousa et al 2020a)), there is evidence that many refactorings performed in practice are not effective (Cedrim 2018, Rebai et al 2020. As a result, DPs end up not being completely removed.…”

“…However, besides not being enough for DP removal, single refactorings are often linked to the introduction of new DPs . Moreover, recent studies show that developers often apply more than one refactoring, even if they aim for small design improvements (Bibiano et al 2019, Brito, Hora and Valente 2020, Tufano et al 2015, Palomba et al 2017. In this chapter, we call such refactoring sequences as composite refactorings.…”