Everything you Wanted to Know About Refactoring but were Afraid to Ask!

By Gary ShortTechnical EvangelistDeveloper Express

Agenda

• What is Refactoring?• Why Should I Refactor?• How do I know that I have to refactor?• How Should I Refactor?• How can Tooling Help Me?• Advanced Refactoring.

Why do I Need to Know this?

• Refactoring is a professional dev skill• Therefore it’s a must have skill for you!• Helps to keep technical debt under control• Technical debt kills projects.

Introduction

• Gary Short– Technical Evangelist for Developer Express– Community Evangelist for... Well, me really! – Microsoft MVP C#

• Where do I hang out?– http://www.garyshort.org (blog)– http://www.twitter.com/garyshort– http://www.sodthis.com (podcast).

How About you Guys?

What is Refactoring?

• Knowledge says refactoring is...– the process of changing a computer program's internal

structure • without modifying its external functional behavior • or existing functionality,

– in order to improve • internal non-functional properties of the software,

– for example to improve code readability, – to simplify code structure, – to change code to adhere to a given programming paradigm,– to improve maintainability, – or to improve extensibility.

Ooo, Hold on, How’d you do That?

• the process of changing a computer program's internal structure – without modifying its external functional behavior – or existing functionality,

• Unit Testing– is a software design and development method where the

programmer gains confidence that individual units of source code are fit for use

– modern applications include the use of a test framework such as nUnit

– each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation.

Quick Example

•October 17, 1989, the 7.1 magnitude Loma Prieta earthquake causes 68 deaths•The earthquake reminded the world that the San Francisco Bay region remains vulnerable•If a Richter magnitude 8.0 or greater earthquake centered near the Bridge, there would be a substantial risk of impending collapse •Retrofit starts 1997•Still ongoing today•Cost ~ half a billion dollars.

Biggest Refactoring Eva!!

Why Should I Refactor?

• Refactoring is our way of paying off our “Technical Debt”

• Technical what?!– is a metaphor developed by Ward Cunningham• doing things the quick and dirty way sets us up with a

technical debt, which is similar to a financial debt• incurs interest payments, which come in the form of

the extra effort that we have to do in future development.

Financial Debt Isn’t All Bad

Borrow

Purchase

Build

Sell

Repay

Technical Debt Isn’t all Bad Either

Borrow

Design

Build

Deploy

Refactor

Refactoring Pays Back this Debt

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec0

102030405060708090

100110120130

No Refactoring

Refactoring Pays Back this Debt

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec0

0.5

1

1.5

2

Refactoring

How Do I Know When To Refactor?

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov0

20

40

60

80

100

Burn Down Graph

How Do I Know When To Refactor?

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov0

20

40

60

80

100

Burn Down Graph

How Do I Know When To Refactor?

0 2 4 6 8 10 120

2

4

6

8

10

12

14

Backlog Items Per Iteration

How Do I Know When To Refactor?

0 2 4 6 8 10 120

2

4

6

8

10

12

14

Backlog Items Per Iteration

How Do I Know When To Refactor?

0 2 4 6 8 10 120

2

4

6

8

10

12

14

Number of Tests Per Back Log Item

How Do I Know When To Refactor?

0 2 4 6 8 10 120

2

4

6

8

10

12

14

Number of Tests Per Back Log Item

How Should I Refactor?

• Ask yourself the following questions– Is my code readable? – Is my code abstract?

• Anything more is rearranging the deck chairs on the Titanic– It gives you a sense of doing something– But ultimately it’s pointless.

Refactoring for Readability #1

Refactoring for Readability #1

Refactoring for Readability #2

Refactoring for Readability #3

Refactoring for Readability #4

Refactoring for Readability #5

Refactoring to Make Abstract #1

Refactoring to Make Abstract #2

Refactoring to Make Abstract #2

Refactoring to Make Abstract #3

Can Tooling Help me?

• Yes, in the following ways– Refactoring can be repetitive• Repetitive tasks bore humans

– Resulting in mistakes

– Solutions can contain many projects• Many classes with many projects can contain the same

method calls– This makes them hard to find and easy to miss

– Tools can suggest refactors that you might not know exist.

Tooling Demo

Refactoring to Patterns #1

Refactoring to Patterns #1

Refactoring to Patterns #2

Refactoring to Patterns #3

Summary

• Refactoring is changing the structure, but not the functionality of your application

• Refactoring is done to pay back the “Technical Debt”

• Refactor by asking is your code– Readable– Abstract

• Invest in some tooling.

Further Reading

• Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2.

• Wake, William C. (2003). Refactoring Workbook. Addison-Wesley. ISBN 0-321-10929-5.

• Feathers, Michael C (2004). Working Effectively with Legacy Code. Prentice Hall. ISBN 0-13-117705-2.

• Kerievsky, Joshua (2004). Refactoring To Patterns. Addison-Wesley. ISBN 0-321-21335-1.

• Arsenovski, Danijel (2008). Professional Refactoring in Visual Basic. Wrox. ISBN 0-47-017979-1.

Questions

• http://www.garyshort.org• http://www.twitter.com/garyshort• http://www.sodthis.com• gary@garyshort.org