Date post: | 19-Dec-2015 |
Category: |
Documents |
View: | 213 times |
Download: | 0 times |
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