Skip to main content

5 Tips to work with legacy code



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

Post a Comment

Popular posts from this blog

Shear waves, medecine and brain

Yesterday evening, too bored by what TV was proposing to me, I decided to watch a conference of Mathias Fink , a french researcher working on multidisciplinary application of waves. Specially shear waves.  Here is a brief summary of his talk. In solids, waves have two principal components:  compression waves (P-waves for primary) moving in the direction of propagation, and shear waves (S-waves, for secondary) that make ripples in the plane orthogonal to that direction. Since compression waves propagate in the direction of propagation, they move faster than shear waves. Usually ultrasound equipment in medicine only use compressional waves. But since human tissues have a high bulk modulus, the P-wave speed is relatively constant (around 1580 m/s). Human tissues are very stiff if you apply isotropic constraints on them (like pressure of water). However M. Fink and his colleagues proposed a new way to investigate human tissues by first sending a strong compressional wave in ...
Post a Comment
Read more

We're not playing dices !

Software programming and design is an amazingly complex task. Specially when it concerns numerical applications, that generally require optimization to get results in a reasonable time. For that purpose the basic pattern is usually to write the code as simple as possible, debug it and when it works to begin the optimization process. This asks for some nerves, and patience, two things I usually don't have in real life , but for programming yes. This design pattern makes sense because we are doing things really sequentially. You first wrote some c++ class and then add some feature progressively, and when you come up with essentially different concept (I mean a concept that should be well separated from the first one), you write an other class and so on... Usually the class-writing process follows the solving process you have in mind. For instance you have to make some initialization on your model first, then you declare some variables for the computation, the computation then f...
Post a Comment
Read more