Working With Legacy Code

Recently I spent some time working with legacy code. The usual stuff - fixing bugs, introducing requested changes. In this blog post I share some comments on working with such code.

First of all what is a legacy code? Definition varies, but usually a legacy code is a code, which was written some time ago, and which has no tests. This means, you have no one to ask about it (original authors are long gone), and you have no clue if the changes you introduce break something. You can also sense legacy code by the aura of mysteriousness and horror around it - people hush when you ask about it, and pretend they do not know what you are asking about.

So now few comments on what I have seen and learned (the hard way).

  • Debugger is your friend. Run the code and see how the execution flows from between classes and methods. Mix debugging sessions with browsing code and reading documentation (if any...).
  • Another definition of legacy code says, that this is every code you wrote longer than a week ago. ;)Add good, informative log messages. Use ReflectionToStringBuilder from Apache Commons Lang to see what is inside objects. Add toString methods along the way, so it is easier to log important information on various classes.
  • It is often easier to test larger parts (modules, layers, whatever you have there), than to untangle all the code mess and do the unit testing. So write some kind of integration tests or end-to-end. In general, adding testability to some old codebase, full of stuff which is hard to call object-oriented, is very hard.
  • Copy&Paste errors are really hard to spot ...or is it only me who is blind to such kind of errors? I spent long time looking at methods which included some copied fragments of code and couldn't find bugs. Anyway, use debugger to see what is really going on there.
  • Do not believe if someone tells you, that "this has been tested and works fine". Bull#(*$! If there is no automated test then it probably does not work. Howgh!
  • Refactor along the way. Even if all you can (safely) do is to rename some variables, so their names are more intention-revealing, then do it. Some time later you (or someone else) will be grateful you did this.
  • Update documentation (if any). Things you find after long hours of learning the codebase are invaluable - write them down to save time of other poor souls who will walk the same paths in the future.
  • Remove unused stuff: useless javadocs, some long forgotten, commented-out code parts. It is all git/svn, you know?

Ok, that is it for the moment. And if you happen to be stuck in legacy code for longer time, then grab the copy of Michael Feather's "Working Effectively With Legacy Code"

And if nothing helps... well, use the stress-relief kit. Always helps. :)

Legacy code is big headache

Hi, i find your blog from google. I am reading some legacy code written. It is really hard for me to understand them. The original owner has left our company. Thanks for you tips. They are very useful, especially for C code. - auto loan calculator | - loan calculator

 
 
 
This used to be my blog. I moved to http://tomek.kaczanowscy.pl long time ago.

 
 
 

Please comment using