By Nicholas Zakas CHAPTER 2it. 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 manag-
ing 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 de-
cisions 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?
wRiTe iT Down
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. 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.