refactoring fest

Licensed Under Creative Commons by Naresh Jain

Refactoring FestNaresh Jain

[email protected]

1

http://creativecommons.org/licenses/by-nc-sa/3.0/


http://agilefaqs.com/nareshjain.html


mailto:[email protected]



Tutorial Schedule

What, Why, When and How... Refactor?

How to Refactor to Patterns

How to deal with Legacy Code?

Refactoring Hands-on session

2






Three Golden Rules

Once and only once [DRY]

Express intent

Tell, don’t ask

3






Definitions

4






Definitions

Loose Usage

4






Definitions

Loose Usage

Reorganize a program (or something)

4






Definitions

Loose Usage


As a noun

4






Definitions

Loose Usage


As a noun

a change made to the internal structure of some software to make it easier to understand and cheaper to modify, without changing the observable behavior of that software

4






Definitions

Loose Usage


As a noun


As a verb

4






Definitions

Loose Usage


As a noun


As a verb

the activity of restructuring software by applying a series of refactorings without changing the observable behavior of that software.

4






What is Refactoring?

5







A series of small steps, each of which changes the program’s

internal structure without changing its external behavior - Martin Fowler

5







A series of small steps, each of which changes the program’s

internal structure without changing its external behavior - Martin Fowler

Verify no change in external behavior by

Testing

Using the right tool - IDE

Formal code analysis by tool

Being very, very careful

5






What if you hear...

6






What if you hear...

We’ll just refactor the code to add logging support

6






What if you hear...


Can you refactor the code so that it authenticates against LDAP instead of Database?

6






What if you hear...



We have too much duplicate code, we need to refactor the code to eliminate duplication

6






What if you hear...




This class is too big, we need to refactor it

6






What if you hear...




This class is too big, we need to refactor it

Caching?

6






Origin

Ward Cunningham and Kent Beck

Smalltalk style

Ralph Johnson at University of Illinois at Urbana-Champaign

Bill Opdyke’s Thesis

ftp://st.cs.uiuc.edu/pub/papers/refactoring/opdyke-thesis.ps.Z

John Brant and Don Roberts: The Refactoring Browser

7






Why do we Refactor?

8






Why do we Refactor?

Helps us deliver more business value faster

8






Why do we Refactor?

Helps us deliver more business value faster

Improves the design of our software

Combat’s “bit rot”

Easier to maintain and understand

Easier to facilitate change

More flexibility

Increased re-usability

8






Why do we Refactor?...

9







Minimizes technical debt

9








Keep development at speed

9









To make the software easier to understand

Write for people, not the compiler

Understand unfamiliar code

9












To help find bugs

refactor while debugging to clarify the code

9












To help find bugs

refactor while debugging to clarify the code

To “Fix broken windows” - Pragmatic Programmers

9






ReadabilityWhich code segment is easier to read?

Sample 1

if (date.before(Summer_Start) || date.after(Summer_End)){ charge = quantity * winterRate + winterServiceCharge;else charge = quantity * summerRate;}

Sample 2

if (isSummer(date)) { charge = summerCharge(quantity);Else charge = winterCharge(quantity);}

10






When should you refactor?

11







To add new functionality

refactor existing code until you understand it

refactor the design to make it simple to add

11










To find bugs

refactor to understand the code

11










To find bugs


For code reviews

immediate effect of code review

allows for higher level suggestions

11










To find bugs


For code reviews

immediate effect of code review

allows for higher level suggestions

Like championship snooker players we are setting ourselves up for

our next shot

11






The Two Hats

Adding Function

Add new capabilities to the system

Adds new tests

Get the test working

Refactoring

Does not add any new featuresDoes not add tests (but may change some)Restructure the code to remove redundancy

12






The Two Hats

Adding Function

Add new capabilities to the system

Adds new tests

Get the test working

Refactoring

Does not add any new featuresDoes not add tests (but may change some)Restructure the code to remove redundancy

Swap frequently between the hats, but only wear one at a time

12






Refactoring and TDD

TDD Rhythm - Test, Code, Refactor

13






Refactoring and TDD


Add a Test

13






Refactoring and TDD


Add a Test

Run the Test

13






Refactoring and TDD


Add a Test

Run the TestPass

13






Refactoring and TDD


Add a Test

Run the Test

Fail

Pass

13






Refactoring and TDD


Add a Test

Run the Test

Make a little change

Fail

Pass

13






Refactoring and TDD


Add a Test

Run the Test


Run the Test

Fail

Pass

13






Refactoring and TDD


Add a Test

Run the Test


Run the Test

Fail

Fail

Pass

13






Refactoring and TDD


Add a Test

Run the Test


Run the Test

Fail

Pass

Fail

Pass

13






Refactoring and TDD


Add a Test

Run the Test


Run the Test

Refactor

Fail

Pass

Fail

Pass

13






Team Techniques

Encourage refactoring culture

nobody gets things right first time

nobody can write clear code without reviews

refactoring is forward progress

14






Team Techniques...

15






Team Techniques...

Provide sound testing base

tests are essential for refactoring

build system and run tests daily

15






Team Techniques...

Provide sound testing base

tests are essential for refactoring

build system and run tests daily

Pair Programming

two programmers working together can be quicker than working separately

refactor with the class writer and a class user

15






How do we Refactor?

We looks for Code-Smells

Things that we suspect are not quite right or will cause us severe pain if we do not fix

16






Common Code Smells

The Big Stinkers

Duplicated code

Feature Envy

Inappropriate Intimacy

Comments

Long Method

Long Parameter List

Switch Statements

Improper Naming

17






Duplicated Code

18






Duplicated Code

There is obvious duplication

Such as copy and paste

18






Duplicated Code



There are unobvious duplications

Such as parallel inheritance hierarchies.

Similar algorithms

18






Duplicated Code



There are unobvious duplications

Such as parallel inheritance hierarchies.

Similar algorithms

Remedies

Extract Method

Pull Up Field

18






Feature Envy

19






Feature Envy

A method that seems more interested in some other class than the one it is in.

19






Feature Envy

A method that seems more interested in some other class than the one it is in.

Remedies:

Move Method

Extract Method

19






Extract Method

20






Extract Methodvoid printOwning(double amount){

printBanner();

// print detailsSystem.Console.WriteLine(string.Format(“name: “, name);System.Console.WriteLine(string.Format(“amount: “, amount);

}

20






Extract Methodvoid printOwning(double amount){

printBanner();

// print detailsSystem.Console.WriteLine(string.Format(“name: “, name);System.Console.WriteLine(string.Format(“amount: “, amount);

}

void printOwning(double amount){printBanner();printDetails(amount);

}

void printDetails(double amount){System.Console.WriteLine(string.Format(“name: “, name);System.Console.WriteLine(string.Format(“amount: “, amount);

}

20





21







Two or more classes fiddling with each other’s private parts.

21







Two or more classes fiddling with each other’s private parts.

Remedies

Move Method and Move Field

Change Bi-directional Association to Unidirectional

Extract Class

21






Extract Class

22






Extract Class

PersonnameofficeAreaCodeofficeNumber

getTelephoneNumber

22






Extract Class

PersonnameofficeAreaCodeofficeNumber

getTelephoneNumber

TelephoneNumber

areaCodenumber

getTelephoneNumber

Person

nametelephoneNumber

getTelephoneNumber

22






Comments

23






Comments

Comments – be suspicious!

23






Comments


Comments are a deodorant.

23






Comments



Comments represent a failure to express an idea in the code.

23






Comments



Comments represent a failure to express an idea in the code.

Remedies:

Extract Method

Rename Method

Introduce Assertion

23






Introduce Assertion

24






Introduce Assertiondouble GetExpenseLimit() { // should have either expense limit or a primary project return(_expenseLimit != NULL_EXPENSE) ? _expenseLimit : _primaryProject.GetMemberExpenseLimit();}

24






Introduce Assertiondouble GetExpenseLimit() { // should have either expense limit or a primary project return(_expenseLimit != NULL_EXPENSE) ? _expenseLimit : _primaryProject.GetMemberExpenseLimit();}

double GetExpenseLimit() {assert(_expenseLimit != NULL_EXPENSE || _primaryProject != null, “Expense Limit and Primary Project must not be null”);

return(_expenseLimit != NULL_EXPENSE) ? _expenseLimit : _primaryProject.GetMemberExpenseLimit();}

24






Long Method

25






Long Method

Good OO code is easiest to understand and maintain with shorter methods with good names

Long methods tend to be harder to read and understand

25






Long Method

Good OO code is easiest to understand and maintain with shorter methods with good names

Long methods tend to be harder to read and understand

Remedies:

Extract Method

Replace Temp with Query

Replace Method with Method Object.

Decompose Conditional

25







double basePrice = _quanity * _itemPrice;

if(basePrice > 1000){

return basePrice * 0.95;}else{ return basePrice * 0.98; }

26







double basePrice = _quanity * _itemPrice;

if(basePrice > 1000){

return basePrice * 0.95;}else{ return basePrice * 0.98; }

if(getBasePrice() > 1000) {return getBasePrice() * 0.95;

}else { return getBasePrice() * 0.98; }

double getBasePrice() { return _quanitiy * _itemPrice;}

26






Long parameter list

27






Long parameter list

Functions should have as few parameters as possible.

27






Long parameter list

Functions should have as few parameters as possible.

Remedies:

Replace Parameter with Method

Preserve Whole Object

Introduce Parameter Object

27







28







Customer

AmoutInvoicedIn(Date start, Date end)AmoutRecivedIn(Date start, Date end)AmoutOverdueIn(Date start, Date end)

28







Customer

AmoutInvoicedIn(Date start, Date end)AmoutRecivedIn(Date start, Date end)AmoutOverdueIn(Date start, Date end)

Customer

AmoutInvoicedIn(DateRange range)AmoutRecivedIn(DateRange range)AmoutOverdueIn(DateRange range)

28






Switch Statements

29






Switch Statements

Type cases are evil because they tend to be duplicated many times.

29






Switch Statements

Type cases are evil because they tend to be duplicated many times.

Remedies:

Replace Type Code with Subclasses

Replace Type Code with State / Strategy

Replace Conditional with Polymorphism.

Replace Parameter with Explicit Methods

Introduce Null Object.

29







void SetValue(String name, int value){

if(name.Equals(“height”)) {

_height = value; return;}if(name.Equals(“width”)){ _width = value; return;}Trace.Assert(false, “Should never reach here”);

}

30







void SetValue(String name, int value){

if(name.Equals(“height”)) {

_height = value; return;}if(name.Equals(“width”)){ _width = value; return;}Trace.Assert(false, “Should never reach here”);

}

void SetHeight(int value){

_height = value;}

void SetWidth(int value){

_width = value;}

30






Inappropriate Naming

31






Inappropriate NamingNames given to variables (fields) and methods should be clear and meaningful.

31



A variable name should say exactly what it is.

Which is better?

private string s; OR private string salary;

31



A variable name should say exactly what it is.

Which is better?

private string s; OR private string salary;

A method should say exactly what it does.

Which is better?

public double calc (double s)

public double calculateFederalTaxes (double salary)

31


Refactoring & Patterns

There is a natural relation between patterns and refactorings. Patterns are where you want to be; refactorings are ways to get there from somewhere else. - Martin Fowler

32






Refactoring to Patterns

33







Creation – creation of objects

33








Simplification – code simplification

33









Generalization – code abstraction

33










Protection – improve protection of existing code

33











Accumulation – information accumulation code

33











Accumulation – information accumulation code

Utilities – misc

33






How to refactor Legacy Code?

34







Identify change points

34








Find an inflection point

34









Cover the inflection point

34










Break external dependencies

34











Break internal dependencies

34












Write tests

34












Write tests

Make changes

34












Write tests

Make changes

Refactor the covered code.

34






Essential Reading

35






Refactoring Hands-on

We’ll use an open source project to apply refactoring lessons

Make sure your laptops are setup with the project

Form pairs and each pair picks up a module/package of the open source project.

36






Refactoring Hands-on...

You will be introduced to 2-3 code smells at a time

Apply lessons form working with legacy code to write tests around your inflection point

Apply lessons from refactoring and refactoring to patterns to eradicate the code smells

Repeat last 3 steps, till we run out of time

37






Thank youRefactoring Fest

Naresh [email protected]

38







refactoring fest

Business

creative commons

naresh jain3

naresh jain1

naresh jain4

refactoring fest naresh

dry express intent

handson sessionlicensed

golden rules