I describe legacy code as any code that you inherit from someone else without a formal hand-off. This frequently happens because the code was written by somebody who no longer works on the project and so managing the code becomes an expedition through unfamiliar territory. You’re expected to be able to fix bugs and extend the previous work without fully understanding what it does or why it was built a certain way. In short, I describe legacy code as code that someone else wrote and that you have to maintain.
I have yet to meet a developer who enjoys working with legacy code. It’s a frustrating experience to have to keep somebody else’s code running without fully understanding it. There’s a natural inclination to believe that everything in the legacy code was done incorrectly and therefore should be completely thrown away to start anew. Practically, you will rarely get the opportunity to start a project completely from scratch, and so it becomes important to understand how to deal with this old code.
But before you can learn how to effectively work with legacy code, you must come to grips with one simple fact: the code you write today is tomorrow’s legacy code. Every line of code you write will eventually be maintained by somebody else. Keeping that in mind helps guide the decisions that you make today about any code that you are working on.
Ask yourself, what will a person who maintains this file need to know in order to work effectively? I often describe working with legacy code as being similar to spelunking, the hobby of exploring caves. In spelunking, you don’t always know what’s around the corner. Caves are dark, wet and not always very stable.
Lastly comment
Delving into legacy code has similar pitfalls in that you may not entirely be sure what each piece of code does. In effect, you are an explorer trying to make sure that the cave doesn’t fall in on you. Making it further into the code is an achievement, and to make it easier for others it helps to draw a map.
