Luận án Tiến sĩ Khoa học Máy tính: Công cụ Refactoring thân thiện với lập trình viên

DISSERTATION APPROVAL The abstract and dissertation of Emerson Murphy-Hill for the Doctor of Philoso- phy in Computer Science were presented on February 26, 2009, and accepted by the dissertation committee and the doctoral program. COMMITTEE APPROVALS: Andrew P. Black, Chair Stéphane Ducasse Mark Jones Susan Palmiter Suresh Singh Douglas Hall Representative of the Office of Graduate Studies DOCTORAL PROGRAM APPROVAL: Wu-chi Feng, Director Computer Science Ph. Program ABSTRACT An abstract of the dissertation of Emerson Murphy-Hill for the Doctor of Philoso- phy in Computer Science presented February 26, 2009.

Title: Programmer Friendly Refactoring Tools Tools that perform semi-automated refactoring are currently under-utilized by programmers. If more programmers adopted refactoring tools, software projects could make enormous productivity gains. However, as more advanced refactor- ing tools are designed, a great chasm widens between how the tools must be used and how programmers want to use them. This dissertation begins to bridge this chasm by exposing usability guidelines to direct the design of the next generation of programmer-friendly refactoring tools, so that refactoring tools fit the way program- mers behave, not vice-versa.

PROGRAMMER FRIENDLY REFACTORING TOOLS by EMERSON MURPHY-HILL A dissertation submitted in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY in COMPUTER SCIENCE Portland State University 2009 To Tetey Acknowledgements This research could not have been accomplished without the help of countless others. First and foremost, thanks to my advisor, Andrew P. Black, for always providing en- lightening guidance and advice. Thanks to the members of my thesis committee, each of whom contributed to this work: Stéphane Ducasse, Doug Hall, Mark Jones, Susan Palmiter, and Suresh Singh.

Thanks to the National Science Foundation for partially funding this research under grant CCF-0520346. Thanks to Ken Brown at the Port- land State Bookstore for donating gift cards as rewards for experiment participants. Thanks to the Computer Science department’s staff for the continuous support and encouragement: Shiva Gudeti, Beth Holmes, Kathi Lee, Rene Remillard, and Bar- bara Sabath. Thanks to my research colleagues Chris Parnin and Danny Dig for their hard work during parts of this research.

Thanks to Gail Murphy, Mik Kersten, Leah Findlater, Markus Keller, and Peter Weißgerber for use of their data. Thanks for Ser- gio Antoy, Andrew Black, Mark Jones, and Len Shapiro for inviting their students to participate in my experiments. Thanks to Robert Bauer, Paul Berry, Dan Brown, Cynthia Brown, Christian Bird, Tim Chevalier, Rob DeLine, Iavor Diatchki, Akshay Dua, Rafael Fernández-Moctezuma, Shiva Gudeti, Tom Harke, Anthony Hornof, Brian Huffman, Ed Kaiser, Rashawn Knapp, Jim Larson, Chuan-kai Lin, Ralph Lon- don, Bart Massey, Kathryn Mohror, Andrew McCreight, David Novick, Nick Pilk- ington, Philip Quitslund, Claudia Rocha, Suresh Singh, Tim Sheard, Jeremy Stein- hauer, Aravind Subhash, Kal Toth, Eric Wheeler, Candy Yiu, and many anonymous reviewers for detailed, insightful criticism. Thanks to Barry Anderson, Robert Bow- iii didge, Margaret Burnett, Jonathan Edwards, Joshua Kerievsky, Gregor Kiczales, Bill Opdyke, Bill Pugh, Jacek Ratzinger, and Vineet Sinha, Mathieu Verbaere, for their suggestions.

Thanks to the participants of the Software Engineering seminar at UIUC for their suggestions. Special thanks to participants of my studies and interviews, without whom this research would have been impossible. Contents Acknowledgements ii Contents iv List of Tables xi List of Figures xiv 1 A Roadmap 1 2 Refactoring Theory 3 2.2 What is Refactoring? .3 When Should Programmers Refactor? .5 A Model of How Programmers Use Refactoring Tools .6 The Structure of this Dissertation .3 The Data that We Analyzed .4 Findings on Refactoring Behavior .1 Toolsmiths and Users Differ .2 Programmers Repeat Refactorings .3 Programmers Often Do Not Configure Refactoring Tools .4 Commit Messages Do Not Predict Refactoring .5 Floss Refactoring is Common .6 Refactorings are Frequent .7 Refactoring Tools are Underused .8 Different Refactorings are Performed with and without Tools 40 3.1 Tool-Usage Behavior .4 Limitations of this Study. 45 4 A Problem with Refactoring Tools 46 4.2 Usability, Guidelines, and the Value of Guidelines Specific to Refac- toring .3 Why Usability is Important to Refactoring Tools .5 An Exploratory Study of Refactoring .1 The Extract Method Refactoring .6 A Survey about Refactoring Behavior .7 Usable Floss Refactoring Tools .1 Principles for Tools that Support Floss Refactoring .2 Tools for Floss Refactoring.

57 5 The Identification Step 60 5.2 Guidelines and Related Work .4 Details of Stench Blossom .2 How Smells were Identified without Stench Blossom 83 5.3 How Smells were Identified with Stench Blossom .4 Suggestions for Tool Improvements .4 Threats to Validity. 92 6 The Selection Step 93 6.4 Threats to Validity .5 Related Work: Alternative Selection Techniques .6 Generalization to Other Refactorings .2 Two More Selection Guidelines .3 Tool Description: Refactoring Cues. 110 7 The Initiation Step 111 7.3 Related Work: Alternative Tool Initiation Techniques .1 Previous Studies: Pie Menus vs.2 Memorability Study: Pie Menus with and without Placement Rules .4 Threats to Validity. 126 8 The Configuration Step 127 8.3 Related Work: Alternative Configuration Techniques .1 Analytical Study: Refactoring Cues vs.1 Analysis by Stepwise Comparison .2 Threats to Validity .2 Opinion Study: Pie Menus, Refactoring Cues, Hotkeys, and Linear Menus .4 Threats to Validity.

142 CONTENTS ix 9 The Error Interpretation Step 143 9.4 Threats to Validity .5 Related Work: Existing Research on Refactoring Errors .6 Generalization to Other Refactorings .1 A Taxonomy of Refactoring Preconditions .1 Methodology for Deriving a Precondition Taxonomy 156 9.3 Application of the Remaining Guidelines to the Taxonomy .3 Example Experiment Run .6 Threats to Validity .1 Summary of Contributions .4 The Thesis Statement. 205 References 210 List of Tables 3.1 Refactoring tool usage in Eclipse. Some tool logging began in the middle of the Toolsmiths data collection (shown in light grey) and after the Users data collection (denoted with a *).2 The number and percentage of explicitly batched refactorings, for all Eclipse tool-based refactorings that support explicit batches. Some tool logging began in the middle of the Toolsmiths data collection (shown in light grey).3 Refactoring tool configuration in Eclipse from Toolsmiths.4 Refactoring between commits in Eclipse CVS.

Plain numbers count com- mits in the given category; tuples contain the number of refactorings in each commit.1 Preconditions to the E XTRACT M ETHOD refactoring, based on Opdyke’s preconditions [58]. I have omitted preconditions that were not encoun- tered during the formative study.1 Some smell names and descriptions .2 Programming experience of subjects.3 Post-experiment results regarding guidelines.1 Total number of correctly selected and mis-selected if statements over all subjects for each tool. 98 LIST OF TABLES xii 6.2 Mean correct selection time over all subjects for each tool.3 The number of times subjects used each tool to select if statements in each code set.1 How refactorings can be initiated using Eclipse 3.3 and my current im- plementation of pie menus, in the order in which each refactoring ap- pears on the system menu (Figure 7.1 on page 112); for pie menus, the direction in which the menu item appears is shown in the third column. I implemented the last three refactorings specifically for pie menus.2 A comparison of initiation mechanisms for refactorings tools.1 Advantages and disadvantages of pie menus and refactoring cues enu- merated by the interviewer, labeled with + for advantage and – for dis- advantage.2 A comparison of selection and configuration mechanisms for refactoring tools.1 The number and type of mistakes when finding problems during the E X - TRACT M ETHOD refactoring over all subjects, for each tool, and the mean time to correctly identify all violated preconditions.

Subjects diag- nosed errors in a total of 64 refactorings with each tool. Smaller numbers indicate better performance.3 In which order the four different groups of subjects used the two refac- toring tools over the two code sets.4 Refactorings and precondition violations used in the experiment. 190 LIST OF TABLES xiii 9.5 The number and type of mistakes when diagnosing violations of refac- toring preconditions, for each tool. The right-most column lists the total mean amount of time subjects spent diagnosing preconditions for all 8 refactorings.

The asterisk (*) indicates that a timing was not obtained for one subject, so I could not include it in the mean. Subjects diagnosed er- rors in a total of 80 refactorings with each tool. Smaller numbers indicate better performance.1 The guidelines postulated in this dissertation. Step indicates a step in the refactoring process (Section 2.

Guideline states a postulated guide- line and the page number where it was motivated. Tools lists my tools that implement that guideline and the page number where the tool was evaluated. 209 List of Figures 2.1 A stream class hierarchy in java. In grey, an equivalent change is made in each version.2 Selected code to be refactored in Eclipse.3 A context menu in Eclipse.

The next step is to select Extract Method. in the menu.4 A configuration dialog asks you to enter information. The next step is to type “isSubnormal” into the Method name text box, after which the Preview > and OK buttons will become active.5 A preview of the changes that will be made to the code. At the top, you can see a summary of the changes.

The original code is on the left, and the refactored code on the right. You press OK to have the changes applied.6 A model of how programmers use conventional refactoring tools. Steps outlined in black are the focus of this dissertation.1 Percentage of refactorings that appear in batches as a function of batch threshold, in seconds. 60-seconds, the batch size used in Table 3.1 on page 23, is drawn in green.2 Refactorings over 40 intervals.

32 LIST OF FIGURES xv 3.3 Uses of Eclipse refactoring tools by 41 developers. Each column is la- beled with the name of a refactorings performed using a tool in Eclipse, and the number of programmers that used that tool. Each row represents an individual programmer. Each box is labeled by how many times that programmer used the refactoring tool.

The darker pink the interior of a box, the more times the programmer used that tool. Data provided courtesy of Murphy and colleagues [47].1 A code selection (above, highlighted in blue) that a tool cannot extract into a new method.2 At the top, a method in java.Long in an X-develop editor. At the bottom, the code immediately after the completion of the E XTRACT M ETHOD refactoring. The name of the new method is m, but the cursor is positioned to facilitate an immediate R ENAME refactoring.1 Examples of a smell visualization in Noseprints [62].

On the left, infor- mation about L ONG M ETHOD for 3 classes, and on the right, information about L ARGE C LASS for 3 other classes. This visualization appears in- side of a window when the programmer asks the Visual Studio program- ming environment to find smells in a code base. Screenshots provided courtesy of Chris Parnin.2 A compilation warning in Eclipse, shown as a squiggly line underneath program code. This line, for example, calls attention to the fact that this expression is being T YPECAST.3 Ambient View, displaying the severity of several smells at the right of the editor.

71 LIST OF FIGURES xvi 5.4 Active View, where the programmer has placed the mouse cursor over a petal representing F EATURE E NVY to reveal the name of the smell and a clickable [+] to allow the programmer to transition to Explanation View.5 Explanation View, showing details about the smell named in Figure 5.1 The Selection Assist tool in the Eclipse environment, shown covering the entire if statement, in green. The user’s selection is partially overlaid, darker.2 Box View tool in the Eclipse environment, to the left of the program code.3 Mean time in seconds to select if statements using the mouse and key- board versus Selection Assist (left) and Box View (right). Each subject is represented as a whole or partial X. The distance between the bot- tom legs represents the number of mis-selections using the mouse and keyboard.