If you’ve been a software developer for any length of time you’ve likely had to deal with legacy code at one point or another. Sometimes it’s a minor annoyance, other times you find yourself dealing with a 30 year old piece of code that is at the core of the application you’re working on. In that case it can feel like you’ve got an albatross around your neck that you just can’t shake… them’s the breaks 😖.
Should I be complaining however? There is that saying about people who live in glass houses, and the unfortunate fact is that we all at one point or another write some less than ideal code, or slack off on some much needed maintenance. The fact is code can be “legacy” the minute it’s written if it is unnecessarily confusing or lacks sufficient tests. And regular maintenace is important! Software is like a house, and if you ignore that leak in the roof, eventually you’ll be looking at an expensive tear down… and no one wants that!
I’ve been ignoring the maintenance of a simple Ruby on Rails application I wrote around 6 years ago. It’s a very simple budget application, but is something I use everyday. It still largely works but a few issues have crept up over the years. I haven’t used Ruby on Rails forever so fixing things up is sure to be a bit of a challenge!
Some general thoughts on dealing with legacy code
When dealing with legacy code, I find the last thing you want to do is be ambitious. That’s kind of a strange thing to say, so what do I mean? I’ve found the approach that works best for me, is to break the work into as many small chunks as possible, even smaller than one would normally. By doing so you can build a feeling of momentum and success early as opposed to feeling frustrated or like you aren’t getting anywhere or accomplishing anything.
For instance, with the budget application we are going to be looking at, I know there is an issue with the category page. I could start by figuring out what is wrong with the category page and fixing it, seems reasonable right? Attempting to tackle this off the bat would be a mistake in my opinion however. Just getting an environment up and running can be a pretty big challenge when dealing with an old piece of code. A lot has to happen before we can even start to look into fixing some bugs. We could easily get discouraged by a perceived lack of progress if we fail to take environment set-up and other steps into account.
I think a more reasonable plan is something along the lines of:
- Review the application, making note of any obvious issues.
- Get the application running locally along with the unit tests.
- Investigate and start to fix the issues indentified in step 1.
So with that in mind let’s take a look at today’s objective.
Today’s objective
We’ve got it pretty easy today, all we’re looking to do is manually run thru the application to re-familiarize ourselves with it (I really only use 2 pages of the application on a regular basis) and to make note of any issues that pop-up.
Let’s start with a quick cruise around the core parts of the application.
A quick over-view the application
As mentionned above, we’re dealing with a simple budget application. The core functionality is to allow the user to enter “transactions” and view reports. We also have some common supporting aspects such as navigation, an about page, a contact page, etc.
Navigation
We’ve got a standard navigation bar at the top of the application:
And likewise a footer at the bottom with a few links:
Viewing / adding transactions
The main view of the application is a list of previous transactions:
This page also contains a link to download all transactions as a CSV file:
There is a simple form available for adding new transactions:
Reporting
The reporting aspect of the application presents the user with a number of charts, and the ability to view the details of the charts.
Pretty simple! There is some date filtering and simple show / hide functionality that we’ll want to make sure is working however.
Categories
The category page allows the user to add or remove categories for their expenses or income, i.e. rent, groceries, pay etc.
Right now navigating to the category page results in a big ole nothing burger 🍔.
Accounts / sign-up
A logged in user can access an account settings page where they can change their email or password, or delete their account.
I’m scared to try any of this functionality as I am not sure if it’s working and don’t want to be locked out of the application if my password gets messed up.
I have noticed that sign-up no longer works, ie.
Results in:
If I enter the bob@example.com email again, I get the following… which makes me think something is likely misconfigured when it comes to emails, so it might not be an application error but a server configuration issue.
The fact sign-up no longer works is actually a good thing as I am using a free Heroku tier to host the application and this has a number of limitations especially around data… as can be seen from the Heroku dashboard below, I’ve used almost half of my allowed database rows so I don’t want anyone using the application other than me and filling up my database!
Something other than an error message would be a better way to enforce this however!
So we now have a pretty good idea of what our application consists of, the next step is to do a more thorough run-thru and see if anything other than what we’ve already discovered is broken.
Hunting for bugs
Manually running thru an application to find bugs is not the most efficient way of going about things, but with a small application it’s not too bad. I checked the entire application, categorized the functionality somewhat, and noted the following:
- Registration / sign in
- Sign in - works
- Sign out - works
- Sign up - errors out with “We’re sorry, but something went wrong.”
- Sign in with Google - works
- Sign in with Twitter - errors out with “We’re sorry, but something went wrong.”
- Accounts
- Change email - unable to test until have sign up working
- Change password - unable to test until have sign up working
- Forgot password - unable to test until have sign up working
- Delete account - errors out with “We’re sorry, but something went wrong.”
- Transactions
- Add - works
- Edit - works
- Delete - errors out with “We’re sorry, but something went wrong.”
- Download CSV - works
- Navigating thru the pages of transactions - works
- Categories - fails to load, errors out with “We’re sorry, but something went wrong.”
- Reports
- Date ranges for all reports - works
- Show / hide details for all reports - works
- Navigation
- Header navigation - works
- Footer navigation - works
- Contact page
- Sending an email - errors out with “We’re sorry, but something went wrong.”
To be honest, much more of the application is broken than I realized. So it’s probably a good thing that I’ve decided to finally do a bit of maintenance.
Summary
We now have a pretty good idea of where we’re at with the application. Although it might not seem like much, we’ve made some good progress; we are much more aware of the state of our application and the scope of the work that lies ahead.
In the next post we’ll grab the code and see if we can get things running locally!
Thanks for reading and I hope you enjoyed the post!