Improving Refactoring with Alternative Program Views

1. Improving Refactoring with Alternative Program Views Emerson Murphy-Hill

2. The Problem with Software Development Tools Software development tools could be a great boon to productivity and program correctness. But current tools can be difficult to use, so much so that developers may be discouraged from using them. How can we improve tools so that programmers are more likely to understand and adopt them?

3. Outline • Introduction to Refactoring • Usability Problems with Current Refactoring Tools • New, More Usable Refactoring Tools • An Experiment to Compare Current to New Refactoring Tools • Conclusions

4. Introduction to Refactoring • Refactoring is restructuring programs while preserving behavior • Examples: renaming variables and methods, encapsulating instance variables, inline method… • Refactoring is good for: • Making programs more understandable • Allowing features to be added more easily • Keeping program development agile • Automated Tools  Behavior-Preservation

5. Extract Method: Crossing Refactoring’s Rubicon • Take a list of statements, move them to a new method, then replace the original statements with a call to the new method • (demo)

6. Refactoring Process with Tools “method of same name already exists…” Change name of other method Pick a Code Segment Select the Code Segment Choose a Name for the New Method (Tool executes code change) Optional: Inspect the New Method

7. Outline • Introduction to Refactoring • Usability Problems with Current Refactoring Tools • New, More Usable Refactoring Tools • An Experiment to Compare Current to New Refactoring Tools • Conclusions

8. What problems do programmers have during Extract Method? • Performed an exercise with programmers, mostly from this department • 9 of 11 programmers encountered an error during Extract Method • One programmer succeeded in only 11 of 34 attempts to extract a method • Programmers frequently had problems selecting whole statements • Programmers had problems understanding error messages • Errors discouraged the programmer from refactoring

9. Outline • Introduction to Refactoring • Usability Problems with Current Refactoring Tools • New, More Usable Refactoring Tools • An Experiment to Compare Current to New Refactoring Tools • Conclusions

10. Some Tool Improvements • Based on the formative exercise, I created three views to improve the process • Two for Selection • “Selection Assist” • “Box View” • One for Interpreting Errors • “Refactoring Annotations” Tools are available at http://multiview.cs.pdx.edu/refactoring

11. Selection Assist • Important Qualities of this View: • It’s lightweight – doesn’t slow down the common case • Programmer selection time is proportional to statement length • Programmer can use keyboard or mouse

12. Tools Similar to Selection Assist

13. Box View • Important Qualities of this View: • Abstracts away code formatting • Selection time is constant for any statement • Programmer can use keyboard or mouse

14. A Tool Similar to Box View Adobe GoLive

15. Refactoring Annotations • Important Qualities of this View: • Indicates the location of errors • Indicates errors relationally (colors, arrows) • Indicates every error (overlaid) • Errors cues are distinguishable • Indicates the amount of work required to recover from error • Distinguishes showstoppers (Xs) from advisories

16. Tools Similar to Refactoring Annotations Eclipse Control Structure Diagrams Dr. Scheme

17. Outline • Introduction to Refactoring • Usability Problems with Current Refactoring Tools • New, More Usable Refactoring Tools • An Experiment to Compare Current to New Refactoring Tools • Conclusions

18. Old Tools Keyboard/Mouse Eclipse Extract Method Wizard New Tools Selection Assist Box View Refactoring Annotations Experiments: Compare Tools Subjects were 16 students from Professor Black’s Object-Oriented programming class.

19. Selection Experiment • Question • Which selection tools help programmers select statements most accurately and quickly? • Methodology • Subjects select all if statements in real code, assisted by Keyboard/Mouse, Selection Assist, and Box View • Measurements • Whether each if statement was selected correctly • The time between consecutive selections

20. Selection Results *All Users Combined*

21. Subjects’ Opinions • 31% said the mouse/keyboard was helpful • 94% said Selection Assist was helpful • 81% said Box View was helpful • 94% said they were likely to use Selection Assist again • 63% said they were likely to use Box View again

22. Extraction Experiment • Question • Which Extract Method tools help programmers understand errors most accurately and quickly? • Methodology • Subjects are given an un-extractable method and told to identify the location of each error using the Eclipse Extract Method Wizard and Refactoring Annotations • Measurements • Whether each error was identified correctly • How long it takes to identify all errors correctly

23. Extraction Results *All Users Combined*

24. Subjects’ Opinions • 56% said Eclipse Wizard was helpful • 100% said Refactoring Annotations were Helpful • 62% were likely to use Eclipse Wizard again • 100% were likely to use Refactoring Annotations again

25. Interpretation of Results (1 of 2) • Programmers are less error prone and faster using Box View and Selection Assist • Programmers like using Box View and Selection Assist • Box View is good when likelihood of mis-selection is high • Selection Assist is good for short code blocks

26. Interpretation of Results (2/2) • Programmers are more likely to understand errors and understand them faster using Refactoring Annotations • Programmers REALLYlike using Refactoring Annotations

27. My Contributions • I have shown that the traditional view used by programmer tools can impede refactoring • I have introduced alternative views to address specific problems • I have demonstrated that these views measurably improve the refactoring process Future Work More user-friendly software development tools may help increase tool adoption, and then yield more productive programmers and less buggy software

28. Thanks… • Advice on Experimental Design: Suresh Singh and Jim Larson • General Advice and Paper Reviews: Robert Bauer, Paul Berry, Andrew Black, Iavor Diatchki, Tom Harke, Brian Huffman, Mark Jones, Chuan-kai Lin, Ralph London, Philip Quitslund, Tim Sheard, and Aravind Subhash • Special thanks to colleagues and students who participated in testing. • Practice talk reviewers

29. References Fowler, M., Beck, K., Brant, J., Opdyke, W. and Roberts, D.: Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional (1999) Fowler, M. Crossing Refactoring's Rubicon. http://www.martinfowler.com/articles/refactoringRubicon.html, (2001) The Eclipse Foundation: Eclipse, http://www.eclipse.org, accessed November 2005 Findler, R., Clements, J., Matthew, Krishnamurthi, S., Steckler, P. and Felleisen, M.: DrScheme: A Progamming Environment for Scheme. Journal of Functional Programming, 12(2):159-182, (2002) Adobe Systems Incorporated: Adobe GoLive. http://www.adobe.com/products/golive, accessed November 2005 Hendrix, D., Cross, J., Maghsoodloo, S. and McKinney, M.: Do Visualizations Improve Program Comprehensibility? Experiments with Control Structure Diagrams for Java. Haller, S. (ed.): In Proc. Thirty-First SIGCSE Technical Symposium on Computer Science Education, Vol. 32. pp. 382-386. ACM, Austin, Texas (2000)

30. Questions?

31. Per-Subject Selection Results

32. Per Subject Extraction Results

33. Helpfulness of Selection Tools

34. Helpfulness of Extraction Tools

35. Likely-to-use-again: Selection Tools

36. Likely-to-use-again: Extraction Tools