As engineers, we like to move things forward and, for those who have a little bit of experience (like me), having to work with legacy code can be a huge set back because we know it can be long, painful and slow-paced. But you don't have to make it harder that it needs to be for you and your team! Below are some common mistakes that occur when working with legacy code and possible ways to overcome them.
1. Should you really use it?
That's probably the first and foremost question. Is it really necessary for your application to tap into this legacy code? Have you done extensive researches to see if there isn't a more modern library out there, with better licensing, design, architecture, library initialization, newest code features, documentation, unit tests, whatever than this old piece of code which is on your shelves?
In case there is, ponder with caution the possible consequences of any choice, using as many criteria that you care for! Remember that this is an important chance that you and your team will have to carry for probably many months or years, so, please, be rational and pragmatic.
2. Don't touch it!
Now the choice is clear, you need to use this piece of legacy code.
But, really, if you can: don't touch it. Embark it. Embed it. Make it containerized. Scoped through extremely rigid and thin APIs with narrow and deep functionalities (rather than large and general).
Overall, minimize the surface of contact between your application that you control on a day-to-day basis and the legacy code you may want to embark.
3. Work Surgically
Legacy code can be very intricate, it may have developed by another team or even by another company. It may follow different rules than those your familiar or comfortable with, and has probably different requirements than those that you may expect. Also, it may follow different rules than those described in its documentation.
Therefore do not try to apply your principles. Do not modify some variables names because they don't strictly conforms to YOUR rules. Do not refactor code because "it will make it better designed".
Any change, even with good intentions, can be a bullet in your foot later.
Try to be as minimalist as possible. Don't think as an engineer, think as a surgeon.
4. Secure your zone with Non-Regression Tests
Still stating the obvious but you need to know that you didn't break anything. And that means, for instance, writing a good number of non-regression tests that would help you to insure that the code that you may modify is still perfectly functional.
It requires a lot of science and art to write good non-regression tests and they are often overlooked. But in this situation they are your friend.
5. Do not assume. Test.
This legacy code may have been written with different principles, coding rules and constraints that makes it intrinsically different from your current code base. And some of those might really be only implicit and it difficult to retro-engineer them.
So by modifying the code, you're basically walking (or running!) in uncharted territories, therefore you don't want to believe that it works, you want to know that it works.
Making assumptions about how it should work is very different than knowing how it works and that's why you need to be pragmatic. Avoid to bend your internal model of the functioning code to match some louse expectations in the real life. So you need to be stringent, exhaustive and crystal-clear about what you expect and what you get. It may imply many hours to find some thorny issues, but you'll get a practical knowledge out of it.
Comments