Programmer-Friendly Refactoring Toolspeople.engr.ncsu.edu/ermurph3/presentations/ThesisProposalPresentation.pdf•At Agile Open NW, people didn’t use tools because of usability problems

1

multiview

Programmer-Friendly

RefactoringTools

Emerson Murphy-Hill

2

multiview

Thesis Statement

Applying a set of user interface

guidelines will allow us to build more

usable refactoringtools.

3

multiview

Where We’re Going…

•What refactoringis and why tools are

good in theory, but not so good in

practice

•Whenprogrammers refactor…

•…and how they refactor

•What I propose to do

•The Big Picture

4

multiview

What is Refactoring?

•Two types of program modification

(Opdyke, 1992)

–Behavior changing

•Calling new methods

–Refactoring: Behavior preserving

•Renaming variables

•Moving methods

•Inlining/Extracting methods

•Tools proposed to automate refactoring

originally proposed by Roberts+ (1997)

+ colleagues

5

multiview

The Promise of Tools

1.Faster than refactoringby hand

2.Much more accurate than by hand

•Xing and Stroulia(2006) report that

refactoringmakes up 70% of

changes to software.

•So if people used refactoringtools,

software would be much better!

6

multiview

But refactoringtools don’t

really help build better software…

because programmer’s don’t use the

tools as much as they could.

7

multiview

Under-use of RefactoringTools

•In our Object-Oriented programming

class, very few students use refactoring

tools (Murphy-Hill, 2006)

•Only 2 of 31 users of the Eclipse IDE here

at PSU have used refactoringtools (usage

history analysis, 7/11/06 through 4/26/07)

•At Agile Open NW, people reported to use

refactoringtools only 2/3 of the time

(survey of 112 attendees)

8

multiview

Why Don’t People Use

RefactoringTools?

•At Agile Open NW, people didn’t use tools

because of usability problems (112 people):

–Not enough flexibility (n=44)

–Haven’t learned tool (n=26)

–Faster to refactor by hand (n=24)

•Usability problems I observed during Extract

Method experiments (Murphy-Hill, 2006):

–Programmers have problems selecting code for input to

refactoringengine

–Programmers have problems understanding errors

generated by refactoringtools

9

multiview

Where We Are…



practice




•The Big Picture

10

multiview

Two RefactoringProcesses

Do people refactor while they program?

Floss Refactoring

Or do people refactor in clumps?

Root Canal Refactoring

RR

RR

RR

R

RR

RR

RR

R

AA

A

AA

A

11

multiview

Floss vs. Root Canal

•Floss

–Impromptu: refactor whenever you think the code needs

it

–You know exactly what code you’re going to refactor,

because you’re working on it

–In Fowler (1999), Parnin+ (2006), Hayashi+ (2006)

•Root Canal

–Planned: set aside time for refactoring

–You don’t know what needs to be refactored, but past

experience indicates future changes will be difficult

–In Van Emden+ (2002), Pizka(2004), Kataoka+ (2002)

12

multiview

Why the Distinction Matters

I claim that a tool

built for root canal

refactoringwill not

be very usable for

floss refactoring,

and to a lesser

degree, vice versa.

Van Emden’s+

smell detector

(2002)

Hayashi’s

smell

detector

(2006)

Roberts and

Brant’s RB scripts

(2004)

Eclipse’s

Move

Method

Root Canal

Tool

Floss

Tool

13

multiview

Root Canal: Ineffective

•Pizka(2004) describes a root canal

refactoringover 5 months; concludes that

the time was mostly wasted.

•Bourquinand Keller (2007) describe a root

canal refactoringover 7 months; showed

few objectively positive results, but did

note a dramatic increase in duplicated

code.

14

multiview

Root Canal: Not Widely

Practiced

•Past:

–In the history of 3 OSS projects, Weißgerber

and Diehl (2006) found that there were no

days of pure refactoring

–In Murphy and colleague’s data (2006), less

than 1% of repository commits contained pure

refactoring

•Future:

–Floss refactoringis central to Agile processes;

as Agile is more widely adopted, floss will be

more widely adopted

15

multiview

Motivation for My Research On

Floss Refactoring

•Mainstream refactoringtools:

–Built largely for floss refactoring

–Haven’t changed much since the first refactoringtool

(Brant and colleagues, 1997)

•Tools described in the research:

–Built largely for root canal refactoring

–Have improved significantly

•Research tools haven’t been accepted in

mainstream development

•This research will focus exclusively on floss

refactoring

16

multiview

Where We Are…



practice




•The Big Picture

17

multiview

The RefactoringProcess

Identify

Code

Select

Code

Configure

Apply

Refactor

Interpret

Results

OK

Interpret

Error

Error

Activate

Unexpected

Result

Clean Up

OK

18

multiview

Narrowing Scope of Work

My Prior Work

My Proposed Thesis Work

19

multiview

Research Process

1.Expose usability problems at each stage

2.Postulate usability guidelines

3.Implementing a new tool based on those

guidelines

4.Validate that usability is improved

5.Refine usability guidelines for future

refactoringtools

20

multiview

Where We Are…



practice




•The Big Picture

21

multiview

Identifying Code for

Refactoring

Postulated Guidelines:

–Show smells for current

code only

–Smells should be

determined incremental

–Smells should not be

distracting

Tool Preview:Editor

overlays

Tool Scope:Same

smells as Slinger,

2005.

Validation: demonstrate

that this tool can help

the programmers

more quickly and

accurately expose

smells versus a

Slinger-like tool

22

multiview

Selecting Code for

Refactoring


–It should be impossible

to make an invalid

selection

–Selection should be

uniform for all

refactorings

–Selection should be

possible to perform

repetitive refactorings

User Study:How do people

select code for repetitive

refactorings?

Tool Preview:Editor Overlays

Tool Scope:Same

refactoringsas Eclipse.

Validation:demonstrate that

programmers can select

code more quickly and

accurately for single and

repetitive refactoringsthan

with standard Eclipse tools

23

multiview

Activating a Refactoring


–Be consistent

–Be memorable

–Provide feedback

Tool Preview:Gestural

menus. (similar to

marking menus,

Kurtenbachand Buxton

2004)

Tool Scope:Majority of

Eclipse refactorings

Validation:demonstrate that

this tool can help the

programmers quickly and

mnemonically activate

refactoringswhen

compared to menus and

hot keys

Pull

Up

Push

DownExtract

Inline

24

multiview

Interpreting Refactoring

Results


–Do not disorient the

programmer

–Make programmer aware of

the extent of changes

–Show results of multiple

refactorings

Initial Study:How

programmers use and

understand the standard

diff tool

Tool Preview:Editor overlays

and refactoringhistory

Tool Scope:Same

refactoringsas Eclipse

Validation:show that

programmers can quickly

and accurately understand

the scope of changes

versus the Eclipse tool

25

multiview

Interpreting Refactoring

Errors


–Be specific about

problem locations

–Use different

representations for

different error types

–Give an indication of

the amount of work

required to recover

•Tool Preview:Editor

overlays, icons

•Tool Scope:

Explanatory subset of

preconditions for

Eclipse refactorings

•Validation:show that

tool helps

programmers quickly

and accurately

diagnose violated

refactoring

preconditions

26

multiview

Where We Are…



practice




•The Big Picture

27

multiview

Contributions So Far

•For one refactoring(Extract Method):

–Observations about usability problems (code

selection and poor error messages)

–Validated solutions

–Usability guidelines

•Distinction between Floss and Root Canal

–Existing research tools built for Root Canal, but

–Floss refactoringis more widely practiced and

successful

28

multiview

Proposed Thesis Work

(estimates in calendar weeks)

Other relevant

work:

–Publications

–Thesis writing

(15 weeks)

34

Activate

Refactoring

4Interpret

Errors

34

1Interpret

Results

51

Select

Code

37

Identify

Code

Tool

Evaluation

Tool

Building

Initial

Study

29

multiview

Future Work

(beyond dissertation)

•Investigate four remaining

refactoringstages

•Validate guidelines independently

•Evaluate tools in case-study

•Verify that better user interfaces

increase adoption and use of

refactoringtools

30

multiview

References

F. Bourquinand R. Keller, “High-impact refactoringbased on architecture violations,”Proceedings of CSMR 2007.

M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring: Improving the Design of Existing Code:

Addison-Wesley Professional, 1999.

S. Hayashi, M. Saeki, and M. Kurihara, "Supporting RefactoringActivities Using Histories of Program

Modification," IEICE Transactions on Information and Systems, 2006.

Y. Kataoka, T. Imai, H. Andou, and T. Fukaya, "A quantitative evaluation of maintainability enhancement by

refactoring," presented at International Conference on Software Maintenance, 2002.

G. Kurtenbachand W. Buxton, “User learning and performance with marking menus,”Proceedings of SIGCHI

1994.

M. Mäntylä, and C. Lassenius, "Drivers for software refactoringdecisions," presented at ISESE '06: Proceedings

of the 2006 ACM/IEEE international symposium on International symposium on empirical software

engineering, 2006.

G. Murphy, M. Kersten, and L. Findlater, "How Are Java Software Developers Using the Eclipse IDE?," IEEE

Software, 2006.

E. Murphy-Hill. Improving Refactoringwith Alternate Program Views. Research Proficiency Exam, Portland State

University, Portland, OR, 2006.

W. Opdyke, "RefactoringObject-Oriented Frameworks," University of Illinois at Urbana-Champaign, Ph.D. Thesis.

1992.

M. Pizka. “Straightening Spaghetti Code with Refactoring.”In Proc. of the Int. Conf. on Software Engineering

Research and Practice -SERP, pages 846-852, Las Vegas, NV, June 2004. CSREA Press.

D. Roberts, J. Brant, and R. Johnson, "A refactoringtool for Smalltalk," Theor. Pract. Object Syst., vol. 3, pp.

253-263, 1997.

D. Roberts and J. Brant, "Tools for making impossible changes -experiences with a tool for transforming large

Smalltalk programs," IEE Proceedings -Software, vol. 151, pp. 49-56, 2004.

S. Slinger, "Code Smell Detection in Eclipse," Delft Universityof Technology, Masters Thesis. 2005.

E. Van Emden and L. Moonen, "Java Quality Assurance by Detecting Code Smells," presented at WCRE '02:

Proceedings of the Ninth Working Conference on Reverse Engineering (WCRE'02), 2002.

Z. Xing and E. Stroulia, "RefactoringPractice: How it is and How it Should be Supported -An Eclipse Case

Study," presented at Software Maintenance, 2006. ICSM '06. 22nd IEEE International Conference on,

2006.

31

multiview

Fruity Example

class FruitCounter{

intfruitCount= 0;

void incrementIfBanana(StringfruitName){

if(fruitName.equals("banana"))

fruitCount++;

} void incrementIfApple(StringfruitName){

if(fruitName.equals("apple"))

fruitCount++;

}

}

32

multiview

Demonstrating Usability

Problems

•How to verify that usability is a

problem with refactoringtools:

–Show how tools don’t meet existing

human-computer interaction principles

–Show the problems people have when

doing refactoringusing tools

–Show how tool usage differs from

general refactoringtask model

33

multiview

How Programmers Refactor

•(DEMO)

•Take notice:

–Which steps I do to use refactoringtools

–In what order I refactor

34

multiview

Expected Contributions

1.A set of observations about the use of

refactoringtools during programming

tasks, specifically including deficiencies

with current tools.

2.A refactoringtoolset built on top of an

existing environment, validated by

controlled experiments comparing the

new tools to existing tools.

3.A set of guidelines for building future

refactoringtools.

Documents

Programmer-Friendly Refactoring Toolspeople.engr.ncsu.edu/ermurph3/presentations/ThesisProposalPresentation.pdf•At Agile Open NW, people didn’t use tools because of usability problems