Sunday, July 20, 2008

Refactoring

What is refactoring?

"Refactoring is the art of safely improving the design of existing code. The purpose of refactoring is to make software easier to understand and modify".

(Refactoring, Martin Fowler, 1999)

"Rewriting, reworking and rearchitecting code is collectively know as refactoring. Refactoring your code (moving functions around and updating early decisions) is really an exercise of PAIN MANAGEMENT. Changing source code around can be pretty painful. Let face it! "

(The Pragmatic Programmer, Dave and Thomas, 1999)

Refactor early, refactor often

(The Pragmatic Programmer, Dave and Thomas, 1999)

Why we need to do refactoring?

Increasing code value

  • A significant fraction of our valuation is the state of our code base
  • A low quality code base is a liability
  • Microview: coding convention
  • Macroview: program architecture
  • Both microview and macroview are equal important

(YUI Theater — Douglas Crockford: “Quality” )

Paying off code and design bills

"If programmers got paid to remove code from software instead of writing new code, software would be a whole better place".

(Nicholas Negroponte, MIT, OLPC project)

Software development is like gardening, we need to take care of it everyday

"Rather than building construction, software is more like GARDENING. It's more organic than concrete. We constantly monitor the health of the garden and make adjustments as needed. Business people are comfortable with the metaphor of building construction but we're not building skyscrapers - we aren't constrained by the boundaries of physics and the real world. The gardening metaphor is much closer to the realities of software development".

(The Pragmatic Programmer, Dave and Thomas, 1999)

Refactor to make code more maintainable

maintaining code takes 80% of the time, writing new code only takes 20%. (YUI Theater — Nicholas Zakas: “Maintainable JavaScript”)

All Programming is Maintenance Programming

"we spend a large part of our time in maintenance mode, reorganizing and reexpressing the knowledge in our systems.Most people assume that maintenance begins when an application is released, that maintenance means fixing bugs and enhancing features. We think these people are wrong. Programmers are constantly in maintenance mode. Our understanding changes day by day. New requirements arrive as we're designing or coding. Perhaps the environment changes. Whatever the reason, maintenance is not a discrete activity, but a routine part of the entire development process."

(The Pragmatic Programmer, Dave and Thomas, 1999)

When should we refactor?

(The Pragmatic Programmer, Dave and Thomas, 1999)

"When you have to add a feature to a program and the code is not structured in a convenient way to add the feature, first refactor the program, then add the feature"

(Refactoring, Martin Fowler, 1999)

Three strikes and you refactor

  • The first time you do something, just do it
  • The second time you wince at duplication, but you do the duplicate thing anyway
  • The third time you do something similar, you refactor

(John Tobler's "Three Strikes" Refactoring Rule, see page 20 )

When should we stop refactoring?

Refactor to "good enough" software

  • know when to stop
  • we can't write perfect software

(The Pragmatic Programmer, Dave and Thomas, 1999)

Refactor to "maintainable code"

Maintainable code is:

  • Understandable
  • Intuitive (seem to be in a right place)
  • Extendable
  • Debuggable

(YUI Theater — Nicholas Zakas: “Maintainable JavaScript”)

How should we refactor?

"before start refactoring, check that you have a solid suite of tests. These tests must be self-checking. Change the program in small steps. If we make a mistake, it's easy to find th bug".

Refactoring cycle

  • choose the worst smell
  • select a refactoring that will address the smell
  • apply the refactoring

(Refactoring, Martin Fowler, 1999)

Note: smell means "bad code", "select a refactoring" and "apply the refactoring" mean select and apply a refactoring method described in Martin Fowler's Refactoring book (extract method, move method, replace conditional with polymorphisms, .. for example).

The rhythm of refactoring

  • test, small change,
  • test, small change,
  • test, small change,
  • ......

(Refactoring, Martin Fowler, 1999)

What is bad smell?

I just list the most common ones

  • Dupplication
  • Long method
  • Large class
  • Long parameter list
  • Devergent change
  • .....

(Refactoring, Martin Fowler, 1999) Note: you can read refactoring book to find the approriate refactoring method for each bad smell. Read this nice lecture CMSC 433: Refactoring Still want to see more? Visit this link

Labels: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)