Refactoring

Martin Fowler 1999 defines refactoring in two ways---in the noun form, and the verb form:

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour.

Refactoring (verb): to restructure software by applying a series of refactorings without changing its observable behaviour.

Both of these definitions carry a common line: "without changing its observable behaviour". Refactoring is the process of restructuring code to make it easier to use, cleaner to work with, and removing Code smells.

Discussion

Refactoring is is a big deal. It overturns the older culture of If it ain't broke don't fix it by allowing developers to change code to meet their own needs, rather than for fixing bugs or adding features. It is an integral part of Agile methods.

Refactoring is much more disciplined than just editing code. It is an anti-hacking practice that reduces code changes to simple, atomic transactions. Martin Fowler 1999 says "the cumulative effect of these small changes can radically improve the design".

According to Martin Fowler 1999, p. xvii, Kent Beck is the foremost "master of the art" of refactoring. Beck has opinions about Why refactoring works.

Refactoring is heavily dependent on Unit testing. Before any code is refactored, a test suite should be developed. It is used to check that the refactoring didn't break anything. If you are performing a series of small refactorings, run the tests between each one. This makes it easy to identify & fix bugs immediately.

The culture of refactoring says that, if you are looking at some code and you see a way to make it better, you should. You should also refactor if you can't understand what it does. Fowler argues that this Refactoring and design approach makes a big difference to design culture.

Fowler also discusses Refactoring and performance.

Refactoring Techniques

Composing Methods

Extract Method

Inline Method

Inline Temp

Replace Temp with Query

Introduce Explaining Variable

Split Temporary Variable

Remove assignments to Parameters

Replace Method with Method Object

Substitute Algorithm

Moving Features Between Objects

Move Method

Move Field

Extract Class

Inline Class

Hide Delegate

Remove Middle Man

Introduce Foreign Method

Introduce Local Extension

Organising Data

Self Encapsulate Field

Replace Data Value with Object

Change Value to Reference

Change Reference to Value

Replace Array with Object

Duplicate Observed Data

Change Unidirectional Association to Bidirectional

Change Bidirectional Association to Unidirectional

Replace Magic Number with Symbolic Constant

Encapsulate Field

Encapsulate Collection

Replace Type Code with Class

Replace Type Code with Subclass

Replace Type Code with State/Strategy

Simplifying Conditional Expressions

Decompose Conditional

Notes

• If you change the external behaviour of code, you aren't refactoring, you're just coding.
• If you don't have automated tests in place, you don't know whether you changed the behaviour, so you aren't refactoring.
• Refactoring is essential to ideas like Do the simplest thing that could possibly work and You ain't gonna need it.
• Refactoring helps us escape Big design up front.
• Most IDEs now have some level of support for refactoring.

See also

• Ward's wiki pages:
  • [WhatIsRefactoring]
  • [RefactorMercilessly]
  • [WikiPagesAboutRefactoring]
• Refactoring humour:
  • [Refuctoring & Code Smiles]
  • [Writing unmaintainable code]
• Martin Fowler 1999
• Code smells