Free White Papers
Ask the experts
Got a question? Put us to the test
Is it time to clean up your Software?
Print | Email | Digg this story!
Refactoring is the process of improving the structure of existing software without changing its behaviour. Put simply it is a way of "cleaning up" messy code and software systems.
In this article Oakleigh's Stephen Richardson explores the need for refactoring and the benefits it promises to deliver, before sharing some of the best practices for its successful application.
Counteracting Software Entropy
The tendency for software systems to become increasingly complex and costly to maintain over their lifespan is known as software entropy. Real world software systems are very rarely static and even well designed and implemented systems are likely to lose the clarity of their original design and become disorganised as they evolve to respond to new and changing requirements.
This degeneration is not only present once the system is delivered into a production environment. Software developments also suffer from software entropy as the code evolves through the iterations of the development process. Refactoring is an important technique that can be used to counteract the effects of this descent towards disorder and help alleviate the associated spiralling cost.
Refactoring is about removing duplicated or obsolete code to improve the structure of the software and create a more elegant form. A refactor can be as simple as renaming a variable to make it's purpose clearer, replacing duplicated code with a single shared subroutine, or more complex like reorganising part of the code to meet a recognised design pattern.
The end goal however is always to simplify and clarify the code. Although refactoring does not add new functionality or fix bugs if done correctly it will make these subsequent tasks easier. For example adding new functionality to a system might be difficult given the code's current structure, so a developer might refactor it first to make it easier to subsequently add the new behavior.
Refactoring Best Practice
Refactoring is far from being a new technique. Good software developers have always refactored whether they explicitly called it by this name or not. What is more recent is the emergence of a more structured and disciplined approach to refactoring. Starting with Martin Fowler's influential book "Refactoring: Improving the Design of Existing Code"[1] the common software refactors have been documented and categorised and refactoring best practices publicised and refined.
These developments have promoted refactoring to a wider audience and have encouraged its application in a more focussed and efficient manner than may previously have been the case. Tools support is also on the increase, with many of the leading software development tools, like Eclipse and Visual Studio .Net, now offering increasingly sophisticated refactoring operations directly or via third party plug-ins.
Refactoring is Not Bug Fixing
One of the most widely acknowledged refactoring best practices is to always treat refactoring as a distinct activity from bug fixing or adding new functionality. This makes sense because it's far easier and safer to refactor if you're not simultaneously trying to change the functionality. It also makes testing that the refactor has not introduced any bugs straightforward as the software should exhibit exactly the same behaviour as it did before the refactor.
You should also never decide to refactor purely for the sake of it. You refactor because you want to do something else that the refactor will make easier. Typical trigger points for a refactor include:
- Before adding new functionality.
- Before fixing a bug.
- During the development process as part of a code review.
- To improve performance.
Key to Refactoring is Testing
An essential prerequisite for successful refactoring is having a reliable suite of unit tests, preferably automated, to cover the code being changed. Without these to verify that the refactor has not introduced any bugs of its own, the whole process may well be too risky to be worthwhile.
In the agile development methodologies, for example Extreme Programming, the combination of refactoring and automated unit testing is an integral part of the software development cycle.
Developers alternate between adding new tests and functionality and refactoring the code to improve its internal consistency and clarity. Again automated unit testing is a key compliment to the refactoring, validating that the software has not been broken by the refactor.
Five Top Refactoring Tips
To wrap things up I'll leave you with a summary of my top five refactoring tips:
- Always make refactoring an integral part of your software development and maintenance cycles.
- Refactor continuously, preferably in small bursts (which are less likely to go wrong) interspersed with the development of new functionality or bug fixing.
- Always back up your refactoring with automated unit tests.
- Keep up to date with the latest with refactoring news - www.refactoring.com is a good place to start.
- Seek out and take advantage of development tools that support refactoring operations and automated unit testing.
References:
Martin Fowler with contributions by Kent Beck, John Brant, William Opdyke and Don Roberts, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 2000; ISBN 02014855672
If you have any questions about the subjects covered in this white paper or you would like to find out more about how Oakleigh Consulting could help your organisation, please contact us on 0161 835 4100 or email us.
Copyright
You may publish, quote or reproduce any white papers on this website on the condition that Oakleigh Consulting Ltd is notified, properly credited (and linked to) as the source, including our URL: www.oakleigh.co.uk.