Refactoring
(→Big Refactorings) |
WarwickIrwin (Talk | contribs) m |
||
| (12 intermediate revisions by 7 users not shown) | |||
| Line 4: | Line 4: | ||
:''Refactoring (verb)'': to restructure software by applying a series of refactorings 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]]. | + | 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]]. An alternative definition is "Extending a program to make it more extensible". |
== Discussion == | == Discussion == | ||
| − | Refactoring | + | Refactoring 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]], expecially [[Test Driven Development]]. |
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". | 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". | ||
| Line 13: | Line 13: | ||
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]]. | 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. | + | Refactoring is heavily dependent on [[Unit testing]]. Before any code is refactored, a self-checking 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. Fowler states that, when refactoring, one needs to know what can go wrong, and figure out how to refactor the program safely, with [[Martin Fowler 1999]] providing safe steps for the various types of refactoring. |
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. | 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]]. | + | Fowler also discusses [[Refactoring and performance]]. |
==Refactoring Techniques== | ==Refactoring Techniques== | ||
| + | |||
| + | These techniques are from [[Martin Fowler 1999]]. There are more techniques [http://refactoring.com/catalog/index.html here (refactoring.com)]. | ||
| + | |||
===Composing Methods=== | ===Composing Methods=== | ||
[[Extract Method]] | [[Extract Method]] | ||
| Line 121: | Line 124: | ||
[[Introduce Parameter Object]] | [[Introduce Parameter Object]] | ||
| − | |||
| − | |||
[[Remove Setting Method]] | [[Remove Setting Method]] | ||
| Line 136: | Line 137: | ||
[[Replace Exception with test]] | [[Replace Exception with test]] | ||
| − | ===Dealing with | + | ===Dealing with Generalisation=== |
[[Pull Up Field]] | [[Pull Up Field]] | ||
| Line 159: | Line 160: | ||
[[Replace Inheritance with Delegation]] | [[Replace Inheritance with Delegation]] | ||
| − | ==Big Refactorings== | + | ===Big Refactorings=== |
[[Tease Apart Inheritance]] | [[Tease Apart Inheritance]] | ||
| Line 167: | Line 168: | ||
[[Extract Hierarchy]] | [[Extract Hierarchy]] | ||
| − | |||
| − | |||
== Notes == | == Notes == | ||
| Line 179: | Line 178: | ||
== See also == | == See also == | ||
* [[Ward's wiki]] pages: | * [[Ward's wiki]] pages: | ||
| − | ** | + | ** [http://c2.com/cgi/wiki?WhatIsRefactoring WhatIsRefactoring] |
| − | ** | + | ** [http://c2.com/cgi/wiki?RefactorMercilessly RefactorMercilessly] |
| − | ** | + | ** [http://c2.com/cgi/wiki?WikiPagesAboutRefactoring WikiPagesAboutRefactoring] |
| − | ** | + | ** [http://refactoring.com/ Refactoring.com] Maintained by [[Martin Fowler]] |
* Refactoring humour: | * Refactoring humour: | ||
| − | ** | + | ** [http://www.waterfall2006.com/gorman.html Refuctoring & Code Smiles] |
| − | ** | + | ** [http://mindprod.com/jgloss/unmain.html Writing unmaintainable code] |
* [[Martin Fowler 1999]] | * [[Martin Fowler 1999]] | ||
* [[Code smells]] | * [[Code smells]] | ||
| + | |||
| + | {{Refactoring}} | ||
Latest revision as of 08:51, 16 December 2011
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. An alternative definition is "Extending a program to make it more extensible".
Contents |
Discussion
Refactoring 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, expecially Test Driven Development.
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 self-checking 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. Fowler states that, when refactoring, one needs to know what can go wrong, and figure out how to refactor the program safely, with Martin Fowler 1999 providing safe steps for the various types of refactoring.
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
These techniques are from Martin Fowler 1999. There are more techniques here (refactoring.com).
Composing Methods
Remove assignments to Parameters
Replace Method with Method Object
Moving Features Between Objects
Organising Data
Replace Data Value with Object
Change Unidirectional Association to Bidirectional
Change Bidirectional Association to Unidirectional
Replace Magic Number with Symbolic Constant
Replace Type Code with Subclass
Replace Type Code with State/Strategy
Simplifying Conditional Expressions
Consolidate Conditional Expression
Consolidate Duplicate Conditional Fragments
Replace Nested Conditional with Guard Clauses
Replace Conditional with Polymorphism
Making Method Calls Simpler
Replace Parameter with Explicit Methods
Replace Constructor with Factory Method
Replace Error Code with Exception
Dealing with Generalisation
Replace Inheritance with Delegation
Big Refactorings
Convert Procedural Design to Objects
Separate Domain from Presentation
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:
- Refactoring humour:
- Martin Fowler 1999
- Code smells
