Prior research studies have suggested that most automated refactorings are greatly underused, i.e. programmers usually perform refactorings manually even though modern IDEs provide automated support for those refactorings. Our primary research question was: "Why do programmers underuse automated refactorings?" Eventually, we learned not only about the underuse of automated refactorings but also their unrecommended uses. However, this post focuses on the underuse of automated refactorings.
We decided to collect both quantitative and qualitative data to understand why programmers do not take full advantage of automated refactorings. We used the quantitative data to study the usage patterns of automated refactorings and the qualitative data to understand why programmers use or don't use the automated refactorings in certain ways. We developed CodingSpectator to collect the quantitative data about the usage of automated refactorings, and interviewed several programmers to collect the qualitative data.
We analyzed the data that CodingSpectator collected from 26 programmers for a total of about 1400 hours of programming. Also, we interviewed nine of our participants. Based on these data, we found the following reasons for not using automated refactorings:
- There is less opportunity for some refactorings. For example, programmers perform Pull Up and Extract refactorigs more often than Push Down and Inline because programmers usually refactor to generalize than specialize.
- Most programmers just know about two-thirds of automated refactorings supported by Eclipse.
- The names of some automated refactorings are not descriptive. As a result, some programmers don't even try these refactorings. For example, the majority of our interviewees couldn't tell the difference between three automated refactorings: Infer Generic Type Arguments, Generalize Declared Type, and Use Supertype Where Possible.
- Usability problems damage programmers' trust in automated refactorings. Such usability problems seem to affect programmers' trust in refactoring tools more than the occasional bugs of refactoring engines.
- Programmers are reluctant to use automated refactorings whose outcomes are difficult to predict. Most of the automated refactorings that our participant used affected a small part of the code. Perhaps, one of the reasons that refactoring tools allow programmers to preview an automated refactoring before applying it is to make the refactoring predictable. However, we found that programmers rarely preview their automated refactorings because of the usability problems of the preview window.
- Configuration dialogs of refactoring tools disrupt programmers' workflows. In addition, more configuration options make the refactoring tool harder to understand and use.
The above list summarizes some of the reasons that lead to the underuse of automated refactorings. We have proposed several techniques to make automated refactorings used more often. More training on automated refactorings may encourage programmers to make better use of the refactoring tools. Also, picking more intuitive names for automated refactorings, simplifying the configuration dialogs, and improving the predictability of automated refactorings are some other ways of increasing the utilization of refactoring tools. See our publications for more information about the results of our study.