CCD Red Degree Practice - Apply Simple Refactorings

Refactoring is a term that was popularised by Martin Fowler in his book Refactoring: Improving the Design of existing Code. To Refactor a piece of code you make changes to it which improve it but do not change it's external behaviour. This process can be a manual one (which is potentially dangerous) or it can be automated by a tool such as Visual Studio, Refactor Pro! or ReSharper.

In order to adhere to The Boyscout Rule you will need to make changes to the code. The best way to make these changes are to apply a series of Refactorings. This will guarantee that the code gets better but does not break. Two refactorings are recommended at the Red Degree level.

Firstly there is Extract Method. This relatively simple refactoring involves taking several lines of code and hiding them behind a method call. Ensure that the new method is named in such a way that it unambiguously can stand in for the lines of code it is replacing. This refactoring can clean up your code because it effectively raises the level of abstraction that you think at. You can often see where to apply Extract Method because someone will have several lines of code huddled under a comment. The comment is likely the name of your new method.

The second refactoring that is recommended at the Red Degree level is Rename Method. If you find a method which has a name that does not accurately reflect its actions then you should rename it. Obviously care needs to be taken when renaming public APIs.

As mentioned above you can perform these refactorings by hand but the safest way to do them is with a special purpose tool and with a suite of automated unit tests to back you up. That way you can guarantee that you haven't broken anything as you go.

The net effect of applying the above two refactorings are that you will get a lot of small methods with names that reflect exactly what they do. If done well then you will find it much easier to find (and therefore fix or modify) any particular piece of functionality in a particular class.

clean-codecontinuous-improvement
Posted by: Mike Minutillo
Last revised: 27 May, 2011 02:42 PM History

Comments

15 Mar, 2009 01:52 AM @ version 0

Michael,

You said: you can perform these refactorings by hand but the safest way to do them is with a special purpose tool and with a suite of automated unit tests to back you up. That way you can guarantee that you haven't broken anything as you go.

Again, for anyone who may be new to refactoring:

whether you refactor by hand, or using a refactoring tool, having automated tests is essential

As Fowler says:
###############################################################
If you want to refactor, the essential precondition is having solid tests. Even if you are fortunate enough to have a tool that can automate the refactorings, you still need tests.
...
Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code. The tests are essential because even though I follow refactorings structured to avoid most of the opportunities for introducing bugs, I'm still human and still make mistakes. Thus I need solid tests.
...
It is essential for refactoring that you have good tests. It's worth spending the time to build the tests, because the tests give you the security you need to change the program later.
###############################################################

15 Mar, 2009 01:30 AM @ version 0

Hi Michael

You said: To Refactor a piece of code you make changes to it which improve it but do not change it's external behaviour.

I am sure you are aware of what I am about to say, but I think it is important to mention it for any readers who may be new to refactoring:

While all refactoring improves your code, not all behaviour-preserving improvements qualify as refactoring.

As Martin Fowler says:

###################################################

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

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 behavior.

...the purpose of refactoring is to make the software easier to understand and modify. You can make many changes in software that make little or no change in the observable behavior. Only changes made to make the software easier to understand [and therefore to modify] are refactorings. A good contrast is performance optimization. Like refactoring, performance optimization does not usually change the behavior of a component (other than its speed); it only alters the internal structure. However, the purpose is different. Performance optimization often makes code harder to understand, but you need to do it to get the performance you need.

###################################################

No new comments are allowed on this post.