Source-linked AI summary
Why We Refactor? Confessions of GitHub Contributors
Danilo Silva, Nikolaos Tsantalis, Marco Tulio Valente
TL;DR
The paper addresses limited empirical evidence about why developers perform specific refactoring operations. It monitors Java GitHub projects, asks developers to explain recently applied refactorings, and analyzes their responses thematically. The results identify broad maintenance-task motivations, with Extract Method serving the most purposes and manual refactoring remaining prevalent.
Problem
Empirical studies rarely investigate developers’ motivations for specific refactoring operations rather than general refactoring practice.
Method
The researchers monitored Java projects on GitHub, detected refactorings with RefactoringMiner, asked developers about their reasons and IDE support, and analyzed responses thematically.
Results
Refactoring activity was mainly driven by requirement changes and much less by code-smell resolution; Extract Method had 11 motivations, while 55% of refactorings were manual.
Takeaways & Limitations
Refactoring recommendation systems should refocus from code-smell-oriented solutions toward maintenance-task-oriented solutions.
Takeaways & Limitations
The findings are restricted to open-source Java projects hosted on GitHub and cannot be claimed to apply to industrial systems or other programming languages.
Abstract
from arXiv · showhide
Refactoring is a widespread practice that helps developers to improve the maintainability and readability of their code. However, there is a limited number of studies empirically investigating the actual motivations behind specific refactoring operations applied by developers. To fill this gap, we monitored Java projects hosted on GitHub to detect recently applied refactorings, and asked the developers to ex- plain the reasons behind their decision to refactor the code. By applying thematic analysis on the collected responses, we compiled a catalogue of 44 distinct motivations for 12 well-known refactoring types. We found that refactoring activity is mainly driven by changes in the requirements and much less by code smells. Extract Method is the most versatile refactoring operation serving 11 different purposes. Finally, we found evidence that the IDE used by the developers affects the adoption of automated refactoring tools.
1. INTRODUCTION
The paper examines developers’ motivations for specific refactoring operations, addressing limited evidence from actual developer explanations. It argues that motivations extend beyond traditional code-smell resolution toward supporting maintenance tasks such as feature implementation and bug fixing.
- Background: Refactoring improves existing code design without changing behavior, with catalogues traditionally linking operations to code-smell resolution.Extract Method is commonly recommended for decomposing complex methods or eliminating duplication, while Move Method is associated with Feature Envy and Shotgun Surgery.
- Research gap: Existing studies largely examined general refactoring motivations rather than developers’ explanations for specific operations.The study positions itself as investigating recently applied refactorings using actual developer accounts.
- Study contribution: The study analyzes 463 refactorings from 222 commits across 124 popular Java projects hosted on GitHub.
- Research motivation: Motivation catalogues can support automated detection of developers’ reasons by analyzing commit histories and code-change patterns.
- Research motivation: Developers sometimes extract methods to make feature implementation or bug fixing easier, beyond resolving code smells.
2. RELATED WORK
Prior research studied refactoring practice, tools, and general motivations, but rarely investigated why developers perform particular refactoring types. The paper identifies this gap and distinguishes its approach from source-code-only interpretation.
- Refactoring practices: Research on refactoring practices used activity monitoring and multiple data sources to characterize how developers refactor.
- Refactoring tools: Studies of refactoring tools examined factors affecting tool use, including developer experience, selection mistakes, and unclear error messages.
- Research gap: Existing studies generally did not investigate motivations in depth for specific refactoring types.Kim et al. studied general symptoms, while Wang focused on human and social factors rather than technical motivations.
- Research gap: A prior source-code inspection study inferred motivations without asking the developers, making its interpretation potentially subjective and bias-prone.The paper also characterizes manual inspection as tedious and error-prone.
3. RESEARCH METHODOLOGY
The study monitored GitHub repositories, detected refactorings by comparing revisions, manually filtered results, and surveyed developers about motivations and IDE-supported automation. It used RefactoringMiner across selected Java projects and analyzed responses thematically.
- Repository selection: The researchers selected 748 popular, non-fork Java repositories after excluding the lower quartile by commit count.The selection emphasized repositories with greater maintenance activity.
- Examined refactorings: The analysis covered 12 well-known refactoring types, while Rename Class, Method, and Field were unsupported because their detection requires usage-pattern analysis.
- Tool evaluation: RefactoringMiner was evaluated on 120 documented refactoring operations, and the paper reports acceptable accuracy relative to Ref-Finder results.The supplied passages report Ref-Finder’s published precision and recall comparisons but do not state RefactoringMiner’s recall value here.
- Refactoring detection: During a 61-day period, the monitoring system fetched commits and used RefactoringMiner to detect refactorings between successive revisions.RefactoringMiner infers added, deleted, or moved classes, methods, and fields before applying refactoring-identification rules.
- Data filtering: Manual inspection confirmed true positives before developers were contacted, while commits with existing explanations were excluded from questioning.
- Developer survey: Developers were asked why they performed the refactoring and whether they used automated IDE support.The study defined automated refactoring as actions triggering an IDE’s refactoring engine, including menus, shortcuts, or drag-and-drop.
- Response analysis: Thematic analysis independently coded responses, searched for themes, reviewed possible merges, and named final themes through consensus.An Extract Method case retained both reuse and extension labels because the refactoring served both purposes.
- Tool evaluation: RefactoringMiner’s precision exceeded 75% for Extract Method and Move Attribute, while Move Class and Inline Method were lower at 46%.The supplied results also report 58% for Extract Interface and 67% for Move Method and Extract Superclass.
4. WHY DO DEVELOPERS REFACTOR?
The study identified 44 motivations across 12 refactoring types, showing that developers refactor for varied purposes beyond code-smell resolution. Extract Method had 11 motivations, including reuse, readability, extension, testability, compatibility, and API evolution.
- 44 distinct motivations were identified across 12 well-known refactoring types.
- Extract Method: 11 Extract Method motivations included reuse, readability, facilitating extension, removing duplication, improving testability, and preserving backward compatibility.
- Extract Method: 43 instances used Extract Method to create a reusable method, making reuse its most frequent motivation.
- Extract Method: Extract Method was also used to introduce alternative signatures (25 instances), improve readability (21), facilitate extension (15), and remove duplication (14).
- Extract Method: Testability and backward compatibility each motivated Extract Method in 6 instances, with decomposition enabling isolated tests and delegation preserving the public API.
- Other Refactorings: Other refactorings primarily reorganized responsibilities, reuse, dependencies, inheritance, duplication, and naming across classes, attributes, methods, and packages.
5. REFACTORING AUTOMATION
Refactoring was more often performed manually than with IDE tools, and automation rates varied by refactoring type and IDE. Developers cited trust, simplicity, feature availability, familiarity, and awareness as reasons for avoiding tools.
- 55% of valid answers reported manual refactoring, compared with 38% using an IDE engine and 7% using partial automation.
- Rename Package had the highest automation rate at 58%, followed by Move Class at 50%; Extract Method reached 29%.
- Inheritance-related refactorings showed a trend toward manual application, although the remaining types had at most 9 instances for safe conclusions.
- Among 29 developers explaining nonuse of tools, lack of trust was most frequent (10 instances), followed by perceiving simple cases as unnecessary (8).
- Other barriers included missing support for the specific refactoring (6 instances), unfamiliarity with IDE features (3), and failure to recognize tool applicability (2).
- IntelliJ IDEA users had the highest reported automation ratio at 71%, with similar rates for IntelliJ developers and users (73% vs. 70%).
6. DISCUSSION
The discussion shows that refactorings primarily support ongoing maintenance tasks, while Extract Method serves the broadest range of purposes and tool adoption varies by IDE.
- Refactoring Motivations: Extract Method has 11 distinct motivations, including improving testability and enabling recursion.
- Refactoring Motivations: Only two of Extract Method’s 11 motivations target code smells; most facilitate feature development, bug fixing, reuse, or extension.The two smell-related motivations are decomposing methods for readability and removing duplication.
- Refactoring Motivations: Developers frequently use Extract Method to avoid duplication introduced while implementing checks or fixing bugs.
- Refactoring Motivations: Move Class, Move Attribute, and Move Method are commonly motivated by reorganizing elements for stronger functional or conceptual relevance.
- Automated vs. Manual Refactoring: 55% of refactorings were manual, while IntelliJ IDEA users relied more on automated tool support than users of other IDEs.Automated Extract Method rates were 28% in this study and 30% in the comparison study.
- Refactoring Popularity: Refactoring activity appeared in 60.5% of active monitored repositories, excluding frequent renamings from detection.The study detected refactorings in 285 repositories during a 61-day window.
7. THREATS TO VALIDITY
The study’s validity is bounded by its project population, detection method, IDE coverage, and incomplete motivation catalogue, although the sample spans many projects and developers.
- External Validity: Findings are restricted to open-source, Java-based, GitHub-hosted projects and may not apply to industrial systems or other programming languages.Responses came from 222 developers across 124 projects.
- Internal Validity: The refactoring detector achieved 0.93 recall on 120 documented operations, but recall may differ in projects with tangled changes.The approach can miss refactorings that never reach version control, including overlapping sequences applied to the same code.
- External Validity: Monitoring many IDEs would require a separate tool version for each IDE, which constrains broader IDE coverage.
- Construct Validity: The motivation catalogue may be incomplete, especially for less frequent refactorings such as Push Down Method/Attribute and Extract Interface.The authors made responses and motivation themes publicly available for replication and verification.
8. CONCLUSIONS
The conclusions identify maintenance-task changes, especially new features and bug fixes, as the main drivers of refactoring rather than code-smell resolution. They also highlight Extract Method’s versatility, persistent manual practice, and IDE-related differences in tool adoption.
- 8. CONCLUSIONS: Refactoring is mainly driven by requirement changes and much less by code-smell resolution.Only 2 of 11 Extract Method motivations concerned code smells, covering 25% (35/138) of motivation instances.
- 8. CONCLUSIONS: Extract Method serves multiple purposes, particularly code reuse and functionality extension, and also improves testability and supports public API deprecation.
- 8. CONCLUSIONS: Eliminating dependencies is the most common motivation among move- and abstract-related refactorings.
- 8. CONCLUSIONS: 55% of developers refactored manually; inheritance-related tool support was used automatically in only 10% of cases.Move Class and Rename Package were each performed automatically in over 50% of cases.
- 8. CONCLUSIONS: Automated refactoring rates differed by IDE: 71% for IntelliJ IDEA, 44% for Eclipse, and 50% for NetBeans.
- 8. CONCLUSIONS: The authors propose refocusing refactoring recommenders from code smells toward maintenance tasks such as feature and bug-fix requests.They suggest using feature location and requirements tracing to locate relevant code and recommend suitable refactorings.