Updating Old Web Applications

The past few days I've been working on some websites that I wrote years ago. Part of the motivation was to add new features but there were also some bugs that developed when external APIs changed or in some cases disappeared.

Some of it was painless, other parts had me banging my head up against the wall.

I thought I'd document some of the problems I ran across and some of the things that have helped make the update process easier.

Use an Established IDE and Plugins

All of these sites were developed with Java and my IDE of choice for web development NetBeans. There are a number of reasons I chose NetBeans over Eclipse but one of the main ones is it installs with all the tools I needed for most of my web development without having the need to install third-party plugins.

NetBeans was also miles ahead for Swing development at the time.

When plug-ins are part of the core environment it's been my experience that they're maintained better and there is a stronger emphasis on backwards compatibility.

NetBeans has an integrated Tomcat instance which makes things run a little smoother. I can just click one button and my application launches without having to worry about turning on each part of the stack independently.

When an exception is thrown in the application the output is in the IDE and I can just click on the lines of the trace to jump to the code that is a problem.

The integrated debugger is also very powerful.

That said, I did run into one big issue. One of the sites was using a third party plug-in that was based on a library that is no longer updated. The library still works but the plug-in is no longer available for newer versions of the IDE so I'm forced to use an older installation.

One site also relied on a third-party web services API which was shut down which I can't really do anything about.

In the past I got stung really bad when I developed a client's website using an IDE and framework that was great, but now no longer exists. Now I try to keep third-party plugin and library use to a minimum. When that's not the best option I try and stick with those that are established and have an active community.

You Can Never Have Too Many Comments

// and /* */ should be your best friends. Something may seem trivial to you at the time but if you have to go back to the code some time later it might not be as clear.

With Java applications, using JavaDoc comments are even better. Most Java IDEs trigger the display of JavaDoc comments in one way or another making it easy to follow the code flow without jumping back and forth between files trying to understand what's going on.

In the past I used to only add JavaDoc comments to attributes and functions with public access but now I find that making sure all private functions have good JavaDoc style comments is equally important. Even for methods that seem quite trivial at the time.

With each comment I try to relay:

• What the function does
• Why the function does it
• How the function is called giving examples of inputs and outputs when appropriate

Even if I know I'm going to be the only one implementing that method, even if I know that method will only be called once, I try to write it so that someone who has no idea how that function works can implement it. One day that someone could be me.