Programmer-Friendly Refactoring Tools Emerson Murphy-Hill Advisor: Andrew Black Thanks to: Barry Anderson, Sergio Antoy, Robert Bauer, Paul Berry, Dan.

Programmer-Friendly Refactoring Tools

Emerson Murphy-HillAdvisor: 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

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();}

INTRODUCE EXPLAINING VARIABLE

EXTRACT

INTERFACE

RENAME METHOD

72 refactorings named by Fowler*

* Martin Fowler, Kent Beck, John Brant, William Opdyke, and Donald Roberts, Refactoring: Improving the Design of Existing Code. 1999.

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

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.

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 WorkEarly 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 ToolsMealy and colleagues [6]Campbell and Miller [7]

General Usability GuidelinesShneiderman [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.

7

The Approach

Divide and ConquerWhat I Create at Each Step

GuidelinesTool(s)Evaluation

Select

Identify

Initiate Configure Execute

Interpret Results

Clean Up

Interpret Error

Refactor(recursive)

Error

Unexpected Result

OK

EndStart

Undo

More Program Elements to Refactor

8

Finding Opportunities for Refactoring

Fowler catalogs 22 smells: code patterns suggesting that refactoring might be needed

Feature EnvyCastsLarge ClassMagic Number

class Monkey { Edible peel(Banana b){ if(b.isBruised()) return; b.biteOffStem(); b.removeCasing(); b.throwAwayPeel(); return b.innards(); } }

Identify

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<Long>) 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.

*

10

Stench Blossom

Demo

Identify

11

Evaluation

12 programmers used Stench Blossom tofind smellshelp decide whether to refactor

Measureddid they find more smells with Stench Blossom than

without?

Ask themwas Stench Blossom useful?would they use Stench Blossom on their own code?are the guidelines important?

Identify

12

Results

Found more smells? Almost 2x as many (p<.01)Useful for the task? 100% agreeLikely to use it on own code? 93% agreeAre the guidelines important? Generally, yes

Some disagreement, especially expressiveness and availability

Identify

13

The Other 4 Steps

Select

Identify

Initiate Configure Execute

Interpret Results

Clean Up

Interpret Error

Refactor(recursive)

Error

Unexpected Result

OK

EndStart

Undo

More Program Elements to Refactor

14

The Other 4 Steps

Select

Tools Evaluation

1.9 faster than mouse/keyboard 6.2 more accurate than mouse/keyboard

1.3 faster than mouse/keyboard18.5 more accurate than mouse/keyboard

Lim

ited

to E

XTRA

CT M

ETH

OD

Gen

eral

for

All R

efac

torin

gs Analytical Evaluation: at worst, as usable as any other selection mechanism; more usable when refactoring multiple program elements

15

The Other 4 Steps

Select

Identify

Initiate Configure Execute

Interpret Results

Clean Up

Interpret Error

Refactor(recursive)

Error

Unexpected Result

OK

EndStart

Undo

More Program Elements to Refactor

16

Programmers recall where about twice as many refactorings appear, compared to random placement

Programmers can guess the directionto gesture for a given refactoring

The Other 4 StepsTool Evaluation

Initiate

17

The Other 4 Steps

Select

Identify

Initiate Configure Execute

Interpret Results

Clean Up

Interpret Error

Refactor(recursive)

Error

Unexpected Result

OK

EndStart

Undo

More Program Elements to Refactor

18

The Other 4 Steps

Configure

Tool

Evaluation

Analytical Evaluation: as usable as standard modal configuration, but more usable when no configuration is necessary

19

The Other 4 Steps

Select

Identify

Initiate Configure Execute

Interpret Results

Clean Up

Interpret Error

Refactor(recursive)

Error

Unexpected Result

OK

EndStart

Undo

More Program Elements to Refactor

20

The Other 4 Steps

Interpret Error

Tool Evaluation

Lim

ited

to

Extr

act M

etho

dG

ener

al fo

r Al

l Ref

acto

rings

Mockup

Programmers correctly identify problemsignificantly more correctly, and about 3 faster

Programmers correctly identify problemsignificantly faster and more correctly

21

Zooming Out

Select

Identify

Initiate Configure Execute

Interpret Results

Clean Up

Interpret Error

Refactor(recursive)

Error

Unexpected Result

OK

EndStart

Undo

More Program Elements to Refactor

22

Zooming Out

Select

Identify

Initiate Configure

Interpret Error

Have lightweight user-interfaceHelp the programmer overcome unfamiliar or unusual code formattingSeparate character-based selection from program-element selectionBe task specific

Do not overload the programmerShow relationships between code fragments that give rise to smellsEmphasize smells that are difficult to recognize without a toolDo not distract the programmer from her primary taskHelp the programmer estimate the extent of the smell spreadMake smell information as available as soon as possible, with little effort on the part of the programmerDo not stop the programmer from programming while gathering, analyzing, and displaying smellsFirst and foremost point out smells relevant to the current contextHelp the programmer find the source(s) of the problem by explaining why the smell exists

Avoid distracting the programmer from the primary programming taskTry to match how programmers think about refactoring, such as structurally or spatially

Do not force the programmer to configureDo not interrupt the programmer's primary taskDo not obstruct a programmer's access to other tools

Violated preconditions should be quickly comprehensibleShow the location(s) of violationsShow all violationsIndicate the amount of work required to fix violationsDisplay violations relationally, when appropriate Allow programmers to easily distinguish precondition violations advisoriesDifferent representations for different violations

Contribution: Guidelines and Exemplary User Interfaces for Building Future Tools

23

Future Work

The remaining phasesLonger-term, different language evaluationExtension to other static analysisInvestigate further guidelines

24

Conclusion

Thesis StatementApplying a specified set of user-interface guidelines

can help build more usable refactoring tools.

Thesis is ConfirmedI have uncovered specified guidelinesI have concretized them into new refactoring toolsI have verified that usability is improved