Shaun MacRae

I spoke recently at an OBS internal mini-conference about Refactoring (Rewriting, Reworking, and Re-architecting Code), and I thought I should summarize those ideas here.

Refactoring is the art of making changes to the internal structure of software systems without changing the behaviour of the system. Why refactor? Because, refactoring lends itself to software quality and product evolution. Refactoring encourages good system design, and supporting tests. Finally, refactoring enables rapid software development.

There are different contexts in which refactoring may be applicable. A base case, rule of thumb is ‘Three Strikes and You Refactor’. There are also ‘Code Smells’ as defined by Martin Fowler in ‘Refactoring’ (1999). These smells can help us to identify problem areas and with each smell there are a number of possible refactorings that can be applied in an effort to improve the structures.

There are many guidelines for refactoring, but I should mention those I find most imperative. First, build a solid set of tests for the section of code you are planning to refactor. Then, get into the rhythm of ‘test, small change, test, small change,…’. Make a point of not adding function. Ensure that the code is communicating what it is doing clearly. Continue to do upfront design, but don’t try to find the solution. Finally, keep track of things that need to be refactored even if you don’t have time to do the refactoring.

As for tool support, I find the most useful to be Fowler’s book (mentioned above), which contains an entire catalogue of refactorings and the mechanics involved in each. There is also a handy index on the back cover that lists all of the different code smells and potential refactorings for each. As well, there are tools that help to automate the process.

From my experience, refactoring is a hard sell for non-techies, and even for techies who don’t know about refactoring. The most common excuse is that there is not enough time. This is contradicted by the fact that refactoring enables rapid software development, and even when its efforts aren’t paying off immediately, they will always pay off before long. Some will say that refactoring is risky, but the reality is that refactoring first, before making changes, is less dangerous than just adding new code, because touching the code will remind you how it works. The last excuse I would like to highlight is one of performance. Sometimes the better design means poor performance. This trade off can be justified at first though, because performance can be optimized much more effectively when the code is properly factored. If you analyze most programs, you find that they waste most of their time in a small fraction of the code. This means we can make a very minimal change to a module of heavy usage and reap considerable performance gains without compromising the system architecture.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.