Maintenance and Updating of Legacy Code

Introduction

Most developers get saddled with maintaining or updating legacy source code at some point in their career. This is a list of tips that may help you out in such situations.

Background

This compilation is based on advice received from several CodeProject members, as well as my own experiences. Those interested may view the original thread here.
(Note: I accept no responsibility for changes that may occur there after this tip is published.)

Preparation

• Have the original code checked into source control. If you've just received say, a zip file containing everything, create a repository yourself and check it in. Even if your organization provides no such facility, there are plenty of free version control systems available.
• Read the documentation if available.
• Make sure you are clear on how much functionality can be changed, and how much should remain as is. This is especially important if your changes will affect other developers or tech writers.
• Find out how many resources may be put into the code, and how long it is planned to be maintained. The effort worth putting into it will depend on these factors.

Preliminary Testing

• This may not be feasible in some cases, but execute the code and make sure you get a general idea of how it operates. This will help you notice whether you broke anything.
• Test functionality that you plan to change before making any changes.
• If possible, write unit tests for the parts that you plan to change.

Analysis

• Make sure you know what the code does before you attempt any modifications, don't just jump in.
• Read existing comments and any other documentation / help files.
• Identify the core problems, isolate and study them before replacing the code.

Implementation

• Do the actual changes. Check changes into source control regularly.
• Do not modify legacy code more than necessary to implement new features.
• Cleaning up and optimizing are dangerous, you will break things in unexpected places (believe me, I've been there many times).
• Do clean up parts that will make further future updates simpler, the caveat being that you shouldn't put more effort into the cleaning up itself than expected time savings in future.

Documentation

• Comment all your changes, making sure future developers can figure out what you modified.
• Set up a wiki if you think that will help, with links to the source code.

Final Testing

• Test your modifications. Make sure existing functionality is not broken by your changes.
• If you created unit tests in the previous step, run them now and confirm that they pass.

Points to Consider

• Perform regular check-ins, you will be thankful if you break something and have to backtrack. If your company policy forbids checking in of non-working source code, consider setting up your own private repository or branch.
• Do not mix coding conventions, use the same style used within each file (unless specifically instructed not to).
• Split any enormous classes, making them partial and moving the new code to a new file.
• Like with any coding, follow good coding practices, even if the existing source is messed up.
• Do not make any derogatory comments about the existing code or the previous coder.

Conclusion

I hope this has helped you at least a little in your code maintenance tasks. This is by no means an exhaustive list, please feel free to add comments and suggestions at the bottom, and point out any mistakes I may have made.

Acknowledgments

Thanks to everyone who contributed their wisdom in response to my question in the Lounge (Apologies for not mentioning everyone by name directly).

Revision History

• 2010-12-01 First edition