Abstract Developers frequently undertake software change tasks that could be partially or fully automated by refactoring tools. As has been reported by others, all too often, these refactoring steps are instead performed manually by developers. These missed opportunities are referred to as occasions ofdisuseof refactoring tools. We perform an observational study in which 17 developers with professional experience attempt to solve three change tasks with steps amenable to the use of refactoring tools. We found that the strategies developers use to approach these tasks shape their workflow, which, in turn, shape the opportunities for refactoring tool use. We report on a number of findings about developer strategies, demonstrating the difficulty of aligning the kind of refactoring steps that emerge during a change task based on the strategy with the tools available. We also report on findings about refactoring tools, such as the difficulties developers face in controlling the scope of application of the tools. Our findings can help inform the designers of refactoring tools.

As part of software change tasks, software developers frequently make repetitive and error-prone code changes. Many of these changes can be automated by refactoring tools that are available in mainstream development environments, but developers seldom choose to use them, in large part due to the all-or-nothing approach of the tools. In this paper, we propose an alternative interaction model in which a refactoring tool instead generates a set of code change entities that the developer can inspect, edit, discard, or apply at will. Between applications, the tool supports manual edits or even starting a new refactoring, thus enabling stepwise and recursive refactoring in a way current tools can not. Our model addresses multiple usability problems with refactoring tools. In this paper, we motivate and describe the proposed model and discuss challenges related to its implementation.

Although software developers typically have access to numerous refactoring tools, most developers avoid using these tools despite their benefits. Researchers have identified many reasons for the disuse of refactoring tools, including a lack of awareness by the developers, a lack of predictability of the tools, and a lack of need for the tools. In this paper, we build on this earlier work and employ the ISO 9241-11 definition of usability to develop a theory of usability for refactoring tools. We investigate existing refactoring tools using this theory by analyzing how 17 developers experience refactoring tools in three software change tasks we asked them to perform. We analyze qualitatively the resulting interview transcripts based on our theory and report on a number of observations that can inform tool designers interested in improving the usability of refactoring tools. For instance, we found a desire for developers to guide how a refactoring tool changes the code and a need for refactoring tools to describe changes made to developers. Refactoring tools are currently expected to preserve program behavior. These observations indicate that it may be necessary to give developers more control over this property, including the ability to relax it, for the tools to be usable; that is, for the tools to be effective, efficient and satisfying for the developer to employ.