Welcome!

We are all afraid of the code legacy. A project legacy that has been unchanged for years, without being updated, the famous «as long as it works, we don't touch it». The one that imposes, that they call «swampy ground». And, above all, that has no tests (terrifying, eh?).

When it is necessary to modify the behavior of such a code or fix a bug, volunteers are often conspicuous by their absence. Nobody wants to get involved.

But someone has to do it, right? If it's your turn, I'm going to try to make your life a little easier.

Raising the project

First things first: Launch the project in our local environment. Let's see that README.md... If it exists. Hopefully it not only exists, but has useful information.

The project should work. If it is dockerized, you are probably in luck and you just have to adapt the configuration that comes with the Dockerfile. or the docker-compose.yml. to a current version.

If it is not dockerized, put on gloves. I'm going to speak in terms of Ruby as that's what I'm most familiar with, but the concepts should be applicable to any language.

Preparing the environment

Many languages or frameworks include the language (and, very importantly, version of it) they require in some file. This can be in the Node.js package information, in the Gemfile... it depends on the language (and your luck).

If no luck, then a good place to go is to the version of the framework you use, or of some library. For example, if the project requires Rails 3.2, you can go to see what versions of Ruby Rails 3.2 is compatible with and install it, and do the same with other dependencies (such as databases, redis, etc).

It may take a while, but after that you should at least get the project off the ground.

The task: testing

Congratulations, you got the project off the ground. Now it's time to try to test as much as we can. Go little by little, look for a relatively simple class. Something to start with.

The idea here is to take something that is very simple to understand and start running tests that cover at least the most basic cases of what is already implemented. If, on the other hand, you have to fix a bug in something bigger, the time investment in testing the class/s you need to modify will be worth it. You will gain a lot in stability and knowledge.

Of course it will be very difficult to take into account dependencies, business logic and factors that are not as visible (such as workers in the background or an event-driven communication). This can be alleviated if you have the help of someone who knows a lot about business logic, as well as trying to do some testing. end2end once you have some experience with the code.

Next steps

Now we have two possible ways to go: On the one hand, update libraries and language if we intend to modernize the project. On the other, fix the bugs we find and leave it as it is (spoiler: it's probably better to redo it, but a management Maybe he's not so happy about it).

For the first path, you should be able to have a lot of the code covered by the tests. You never know when a major library update will screw things up. Another option is to create a new project with modernized technologies and gradually migrate the code.

For the other way, your best asset is again the tests. Run as many as you can, verify that they pass successfully and, now, run new tests that should be failing until you fix the bug. After that, all tests should pass.

Wrap-up

Congratulations, you have successfully navigated (or at least learned something about) a project. Legacy. It is normal that they give respect, but it is something that we must know how to deal with, since it is very likely that someday we will be the ones who will have to put on the gloves and get into it.

Best regards!

Do you want to continue learning about legacy code? Here's an article we think you'll like here.