A few times during my time as a consultant I’ve been asked to help clean up code or re-architect code that have become hard to maintain. This has given me some insight of how to deal with legacy code and where to begin the untangling of complex code. I’ll give, what I think are good practices as well as some good tips for not creating complex code in the first place.

When I start working on a new code base I may have no or little time for changing code that smells, at least from project management. To some extent I may go about changing code while fixing defects or when doing new implementation. Sometimes that just is not enough to make a prettier big picture. If the code soon will be rendered to complex to update this is the time I start manifest for more resources on architectural changes. My tips and tricks are most useful once you have time at hand to make those long needed changes.

As with any new code I read I first have to understand its intent. Making changes without first knowing what the code does will inevitably lead me to making bad changes. Once I have an understanding for what the code does I tend to follow the following list:

• Making it thread safe. I’m used to Scrum nowadays so what I’ll do is write the name of each class that uses a thread on a Post-IT along with the note “make thread safe”. At first glance I always assume the worst, that is, all the classes that the thread uses are not thread safe.


• Bloated relations. After getting to know a new code base I have found that there is usually a small subset of classes that tend to be the central part of an application. These classes commonly share the attributes of being lengthy and passed around to many other classes as well as deep down in class instantiation hierarchy. If class A instantiate class Q and then passes it to class B which in turn instantiates class C and sends Q along and finally C instantiates D and yet again sends Q along, then Q has been sent down the road three times and chances are it is not feeling any younger at each step. Chances are also that A might not need Q or more likely, C and D only need a small subset of all the fifty or so methods defined by Q. Introduce interfaces, a sometimes forgotten feature of Java. Stick the class to a yellow note.


• Singletons. Hunt down the classes that believe they are so special that they should only be instantiated once. A sound number of singletons in an application should be as close to zero as codingly possible. Again I use the yellow note thingy.


• Single responsibility pattern. I start by making a list of the classes with the greatest number of rows in them (I know this selection is a bit crude but it’s a start) and then I look for classes that may be broken up into two or more classes. It is said that classes, at least in Java, should not be more than 500 rows. Some classes will need to be longer and some much shorter. The number for me has become a trigger, once I see that my class under development is more than 500 rows I stop and ponder about whether the class only is doing one thing or if I have bloated it with more responsibility than intended. And then, yes you’re spot on, another set of yellow notes.


• Overly complex methods. I Use static code analysis tools to find methods that are really lengthy. If I cannot see the entire method on my screen (the screen size may differ, so I choose the most common size within the team, and no, this is not a valid argument to go by a 30” Cinema Display. Any other argument is valid though) I need to refactor it into smaller methods that fit. I will add that this is the absolute maximum size and that I aim for methods that are 15-20 rows long. I write the name of the class down on yellow notes once again.

After this practice I have a whiteboard filled with yellow notes with delicious coding tasks. The priority is in order of appearance on my list. Aside from these five types of issues there are plenty of others. There are things I do while just browsing code, such as formatting code according to style guide and changing variable names into more explanatory. More nifty tricks and details on each step of my list I mean to come back to on the next episode of this legacy code series.

--Fredrik Bäckström