1. Programmer-Friendly Refactoring Tools Emerson Murphy-Hill Advisor: Andrew Black Thanks to: Barry Anderson, Sergio Antoy, Robert Bauer, Paul Berry, Dan Brown, Christian Bird, Robert Bowdidge, Cynthia Brown, Ken Brown, Margaret Burnett, Tim Chevalier, Rob DeLine, Iavor Diatchki, Danny Dig, Akshay Dua, Stéphane Ducasse, Rafael Fernández-Moctezuma, Leah Findlater, Shiva Gudeti, Tom Harke, Doug Hall, Anthony Hornof, Brian Huffman, Mark Jones, Ed Kaiser, Markus Keller, Joshua Kerievsky, Mik Kersten, Gregor Kiczales, Rashawn Knapp, Jim Larson, Chuan- kai Lin, Ralph London, Bart Massey, Kathryn Mohror, Andrew McCreight, Gail Murphy, David Novick, Bill Opdyke, Susan Palmiter, Chris Parnin, Nick Pilkington, Bill Pugh, Philip Quitslund, Jacek Ratzinger, Claudia Rocha, Len Shapiro, Suresh Singh, Vineet Sinha, Tim Sheard, Jeremy Steinhauer, Aravind Subhash, Kal Toth, Mathieu Verbaere, Peter Weissgerber, Eric Wheeler, Candy Yiu, many anonymous reviewers, the National Science Foundation, and interview and experiment participants.

2. Outline What is Refactoring? Refactoring Tools Problem, Related Work, and Approach A Detailed Description of One Part of the Solution A High Level Description of the Remaining Parts of the Solution Future Work 2

3. What Is Refactoring? class Gorilla{ int paws(){ return 4; } class Gorilla{ int paws(){ int pawCount = 4; return pawCount; } class Gorilla implements Primate{ int paws(){ int pawCount = 4; return pawCount; } … interface Primate{ abstract int paws(); } class Gorilla implements Primate{ int feet(){ int pawCount = 4; return pawCount; } … interface Primate{ abstract int feet(); } I NTRODUCE E XPLAINING V ARIABLE E XTRACT I NTERFACE R ENAME M ETHOD 72 refactorings named by Fowler* * Martin Fowler, Kent Beck, John Brant, William Opdyke, and Donald Roberts, Refactoring: Improving the Design of Existing Code. 1999. 3

4. class Gorilla implements Primate{ int feet(){ int pawCount = 4; return pawCount; } … interface Primate{ abstract int feet(); } class Gorilla implements Primate{ int paws(){ int pawCount = 4; return pawCount; } … interface Primate{ abstract int paws(); } Refactoring Tools Refactoring Tools Promise Two Things: (1) Faster than you can change code by hand (2) Less likely to introduce bugs than by hand 4

5. Refactoring Tools are Underused… One Cause is Poor Usability… When People Don’t Use the Tools, then the Promise Goes Unfulfilled A Problem Some Agile programmers said that they didn’t use refactoring tools because they could refactor faster by hand Campbell and Miller: “Unfortunately, many refactoring tools suffer from deep discoverability and usability problems”* (1) Slower Programming(2) Introduction of More Errors *Dustin Campbell and Mark Miller. Designing refactoring tools for developers. In Proc. of the 2nd Workshop on Refactoring Tools, 2008. 5 2 of 16 object-oriented programming students use refactoring tools Agile programmers estimate that they use refactoring tools 68% of the time Of 42 People who have used Eclipse at PSU, only 6 had tried the refactoring tools in 15 months In 40 code changes, Parnin and I found 145 refactorings, but only 16 of those were done with a tool My exploratory study of 11 programmers found that programmers encountered selection and understanding errors Typical refactoring tools do not align with floss refactoring: a common tactic where refactoring and edits are interspersed

6. Prior Work Early Refactoring and Tools Opdyke [1], Roberts [2], Brant, Griswold [3] Fowler and colleagues [4] Many development environments currently have refactoring tools [5] Usability of Refactoring Tools Mealy and colleagues [6] Campbell and Miller [7] General Usability Guidelines Shneiderman [8] Nielsen [9] Tetzlaff and Schwartz [10] [1] William F. Opdyke. Refactoring Object-Oriented Frameworks. PhD thesis, University of Illinois at Urbana-Champaign, Urbana-Champaign, 1992. [2] Donald Bradley Roberts. Practical Analysis for Refactoring. PhD thesis, University of Illinois at Urbana-Champaign, Champaign, IL, USA,1999 [3] William G. Griswold. Program restructuring as an aid to software maintenance. PhD thesis, University of Washington, Seattle,WA, USA, 1992. [4] Martin Fowler, Kent Beck, John Brant, William Opdyke, and Donald Roberts, Refactoring: Improving the Design of Existing Code: Addison-Wesley Professional, 1999. [5] See, for example, Eclipse, Visual Studio, Squeak, and Xcode. [6] Erica Mealy, David Carrington, Paul Strooper, and Peta Wyeth. Improving usability of software refactoring tools. In ASWEC ’07, pages 307–318, 2007. [7] Dustin Cambell and Mark Miller. Designing refactoring tools for developers. In Danny Dig and Michael Cebulla, editors, Proceedings of the 2nd Workshop on Refactoring Tools, 2008. [8] Ben Shneiderman. Designing the User Interface (2nd ed.): Strategies for Effective Human-Computer Interaction. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1987. [9] Jakob Nielsen. Ten usability heuristics. Internet, 2005. http://www.useit.com/papers/heuristic/heuristic list.html [10] Linda Tetzlaff and David R. Schwartz. The use of guidelines in interface design. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 329–333, 1991. 6

7. The Approach Divide and Conquer What I Create at Each Step Guidelines Tool(s) Evaluation Select Identify InitiateConfigureExecute Interpret Results Clean Up Interpret Error Refactor (recursive) Error Unexpected Result OK EndStart Undo More Program Elements to Refactor 7

8. Finding Opportunities for Refactoring Fowler catalogs 22 smells: code patterns suggesting that refactoring might be needed  Feature Envy Casts Large Class Magic Number class Monkey { Edible peel(Banana b){ if(b.isBruised()) return; b.biteOffStem(); b.removeCasing(); b.throwAwayPeel(); return b.innards(); } Identify 8

9. Guidelines Availability | Smells should always be highly accessible during coding Unobtrusiveness | Do not block the programmer from primary coding work Context-sensitivity | Display smells relevant to the programmer’s task Bias | Emphasize smells that are hidden over those that are obvious Scalability | Displayed smells should not overwhelm the programmer Relationality | Show relationships between code that give rise to smells Estimability | Help estimate the extent of smells in code Task-centricity | Do not distract from primary coding task if need is weak Expressiveness | Give an explanation as to why smells exist, not just where (Class ) Class.forName("long"); Identify *Chris Parnin, Carsten Görg, and Ogechi Nnadi. 2008. A catalogue of lightweight visualizations to support code smell inspection. In Proceedings of the Symposium on Software Visualization. * 9

10. Stench Blossom Demo Identify 10

11. Evaluation 12 programmers used Stench Blossom to find smells help decide whether to refactor Measured did they find more smells with Stench Blossom than without? Ask them was Stench Blossom useful? would they use Stench Blossom on their own code? are the guidelines important? Identify 11

12. Results Found more smells? Almost 2x as many (p<.01) Useful for the task? 100% agree Likely to use it on own code? 93% agree Are the guidelines important? Generally, yes S ome disagreement, especially expressiveness and availability Identify 12

13. The Other 4 Steps Select Identify InitiateConfigureExecute Interpret Results Clean Up Interpret Error Refactor (recursive) Error Unexpected Result OK EndStart Undo More Program Elements to Refactor 13

14. The Other 4 Steps Select ToolsEvaluation 1.9  faster than mouse/keyboard 6.2  more accurate than mouse/keyboard 1.3  faster than mouse/keyboard 18.5  more accurate than mouse/keyboard Limited to E XTRACT M ETHOD General for All Refactorings Analytical Evaluation: at worst, as usable as any other selection mechanism; more usable when refactoring multiple program elements 14

15. The Other 4 Steps Select Identify InitiateConfigureExecute Interpret Results Clean Up Interpret Error Refactor (recursive) Error Unexpected Result OK EndStart Undo More Program Elements to Refactor 15

16. Programmers recall where about twice as many refactorings appear, compared to random placement Programmers can guess the direction to gesture for a given refactoring The Other 4 Steps ToolEvaluation Initiate 16

17. The Other 4 Steps Select Identify InitiateConfigureExecute Interpret Results Clean Up Interpret Error Refactor (recursive) Error Unexpected Result OK EndStart Undo More Program Elements to Refactor 17

18. The Other 4 Steps Configure Tool Evaluation Analytical Evaluation: as usable as standard modal configuration, but more usable when no configuration is necessary 18

19. The Other 4 Steps Select Identify InitiateConfigureExecute Interpret Results Clean Up Interpret Error Refactor (recursive) Error Unexpected Result OK EndStart Undo More Program Elements to Refactor 19

20. The Other 4 Steps Interpret Error ToolEvaluation Limited to Extract Method General for All Refactorings Mockup Programmers correctly identify problem significantly more correctly, and about 3  faster Programmers correctly identify problem significantly faster and more correctly 20

21. Zooming Out Select Identify InitiateConfigureExecute Interpret Results Clean Up Interpret Error Refactor (recursive) Error Unexpected Result OK EndStart Undo More Program Elements to Refactor 21

22. Zooming Out Select Identify InitiateConfigure Interpret Error Have lightweight user-interface Help the programmer overcome unfamiliar or unusual code formatting Separate character-based selection from program-element selection Be task specific Do not overload the programmer Show relationships between code fragments that give rise to smells Emphasize smells that are difficult to recognize without a tool Do not distract the programmer from her primary task Help the programmer estimate the extent of the smell spread Make smell information as available as soon as possible, with little effort on the part of the programmer Do not stop the programmer from programming while gathering, analyzing, and displaying smells First and foremost point out smells relevant to the current context Help the programmer find the source(s) of the problem by explaining why the smell exists Avoid distracting the programmer from the primary programming task Try to match how programmers think about refactoring, such as structurally or spatially Do not force the programmer to configure Do not interrupt the programmer's primary task Do not obstruct a programmer's access to other tools Violated preconditions should be quickly comprehensible Show the location(s) of violations Show all violations Indicate the amount of work required to fix violations Display violations relationally, when appropriate Allow programmers to easily distinguish precondition violations advisories Different representations for different violations Contribution: Guidelines and Exemplary User Interfaces for Building Future Tools 22

23. Future Work The remaining phases Longer-term, different language evaluation Extension to other static analysis Investigate further guidelines 23

24. Conclusion Thesis Statement Applying a specified set of user-interface guidelines can help build more usable refactoring tools. Thesis is Confirmed I have uncovered specified guidelines I have concretized them into new refactoring tools I have verified that usability is improved 24