How We Refactor, and How We Know It

Author(s): Emerson Murphy-Hill, Chris Parnin, and Andrew P. Black
Venue: IEEE transactions on software engineering
Date: 2012

Type of Experiement: Survey/Multi-Case Study
Sample Size: 8
Class/Experience Level: Other
Data Collection Method: Observation


In this article, Murphy-Hill, the lead author, with his team gathers some data of refactorings from many sources such as from Eclipse IDE, user feedback, users in general, third-party tools, code histories, and some other version control systems. First, the authors discover that Eclipse users tend to do a lot of renaming and moving more than Toolsmiths users, but there is a pitfall in the analysis because Toolsmiths is more frequent used than Eclipse. Then the authors also find out that programmers refactor so often in a short period of time to perform a composite refactoring. In addition, the authors think that programmers do not really use the configuration of refactoring tools because they find it easier to tweak the code manually after the refactoring. The author says that floss refactoring is common because it is used by programmers to do a specific purpose such as fixing bugs and adding features. Furthermore, the authors discover that quite many refactorings are medium and low level since some programmers refactor to perform local variable extraction, assertion, and so on. The authors also claim that refactoring is a frequent practice based on the occurrence of refactoring activity in the data gathered from the automated user feedback from the Eclipse IDE. These refactorings tends to occurr just before a software release but not other times. However, the authors somewhat claim that refactoring tools are still underused since a programmer may perform a refactoring manually or use a refactoring tool if it is available and the user interface is sufficiently usable. The author also claim that some refactorings are performed with automated tools, and some are not. The authors claim the reasons include simpler user interface for rename refactoring, lack of tool support for some types of refactoring, and no other way to refactor without performing manually.

In conclusion, the authors finds tool-usage behavior of refactoring, developer responses on manual refactoring, refactoring practice in general, and the relationship between the experimental data and tools.