The SquizLog

The Satisfaction of Refactoring

Ah, it feels good when I've refactored some ugly code. I can reflect on how smelly the code used to be and how it is now much more elegant. It now clearly communicates to the developer and has a structure that will allow much easier adaptation.

As I mentioned earlier this month, the twin topics of Refactoring and Design Patterns have been occupying my thoughts recently. In the last week or two I have been exploring Joshua Kerievksy's Refactoring to Patterns book. I can't recommend it highly enough.

Fortunately I've had the opportunity to put some of the ideas into practice. A few years ago I developed a Java application that reads cricket fixtures from a database and, based on an HTML template, generates two sets of pages. One shows the season's fixtures for each team in the club. The other set contains a page for each playing day of the season showing all the matches the club is involved in.

Anyway, I am now in the position where I want to hand this code over to someone else.

A couple of days ago on the train, whilst I was looking at the code in a class called FixtureList I noticed some smelly code. One method in particular, createTeamFixtureList contained far too much logic and it was by no means immediately apparent what that logic was doing. So I had a Long Method smell. The Compose Method refactoring, essentially a succession of Extract Method refactorings, came to my rescue. Nothing extraordinary about that but at least I ended up with a much shorter method that called other methods with names that improved the code communication.

Of course, before I started any refactoring, I made sure that I had some JUnit tests that I could rerun to ensure that the behaviour of the code was preserved.

Moving on, I noticed another code smell: Conditional Complexity. Thinking about the FixtureList class, it became apparent to me that it really should be divided into two classes: DateFixtureList and TeamFixtureList with an abstract FixtureList superclass. But there was also a getFixtureListAsHtml method to consider. This method contained the same sequence of steps regardless of whether the list of fixtures was by team or date. Some of those steps were the same but others were different. Without going into all the details, I ended using the Replace Conditional Logic with Strategy and Form Template Method refactorings.

Now I am much happier with the state of the code. Of course there is more refactoring that I could do but I've got rid of the worst of the smells and will find it much easier to explain the code to someone who will also be learning Java for the first time.

Posted to Software Development by Keith Pitty