Putting your old code to use in a new project

Hey everyone,

For the past few days I've been working on a chemical structure drawing tool, and even though I don't have that much time to work on it this week I've still been making progress. Now, I'm a really lazy programmer, so naturally any code from other projects that I can incorporate shall be incorporated. So it was a really tempting idea to borrow the structure rendering code I wrote for my chemical database program. (Aside: I wrote it last summer and I think the code is terrible ... how things change)

It was a nice setup at the time, there is a Renderer class which handles the actual drawing (via GDI), and a CompoundViewer class which updates the renderer, handles support for more than one compound, allows selection, deletion, etc., and more useful things. 

However, there are several problems that were keeping me from just dropping it in:

• CompoundViewer uses different representations of structures than I'm using now (the old approach was comparatively sloppier) 
• Chemical bonds store the index of the atoms they are bonded to instead of pointers (as they do now) 
• A lot of methods in the old implementation of Compound are absent from the new implementation

 Still, it seems a shame to have to rewrite something that works well. Plus, the code has had numerous fixes for odd issues that I would probably overlook when rewriting. So instead of rewriting the rendering code, I kept it and scrapped the rest. The reasoning? CompoundViewer contains a lot of functionality that is heavily coupled to the old implementation of Compound, and refactoring it would probably be more trouble than it was worth.

To salvage the Renderer class, I added three new interfaces (ICompound, IBond, and IAtom), and the new versions of these classes implemented them. The required methods/properties that went into the interfaces came directly from what the Renderer class used. The good news is that this turned out to be very painless, and each interface only contains a few methods/properties. I was able to get a test up and running that rendered a simple compound correctly.

When I begin on the GUI side of this project, I won't have to rewrite the important code that actually draws the compounds. As a bonus, the Renderer class maintains compatibility with the old versions since they implement the interfaces already. It's like you win twice!

Code review, refactoring, and more...

Today I want to tell you about ensuring that code is maintainable.

Now, in our project we have a Servlet that reads in requests for graph plotting using jqPlot, and it sends these requests off to a GraphsManager which is responsible for making the data into a nice jqPlot-compatible object that can be JSON serialized and sent off to the client.

The code in GraphsManager is a little hairy -- this is because it makes heavy use of generics and some reflection to ensure that it's very general and can work with many different data sets.

Even though our code base is small right now, it still has the ability to become unmaintainable to anyone who didn't write a particular piece of code. So we want to avoid that by having regular code reviews where we share the pieces of code we've written, go through what it's doing (and why), and refactor it to make it more readable and maintainable.

In going through GraphsManager, even simple changes like replacing confusing if conditions with a helper method that has a very clear name, we can make the code a lot more readable for someone that didn't write it. We also discuss why the particular approach was taken, its pros/cons, and possible alternative solutions.

Anyway, we did this at our meeting the other day and I felt it was really constructive. In fact, I'm thinking about refactoring it soon using an entirely different approach that will make it a lot nicer. It also helps that GraphsManager has an extensive series of test cases that will ensure we don't break anything.

So the moral of this story is: Code review is good, and going through your code with someone will reveal its flaws and possible improvements you can make to it.