How Do You Handle Legacy Code When Starting a New Project?

In that case you might as well accept that you are going to ship more bugs, so instead focus on improving the time it takes from delivering bugs to production to detect it to revert it.

• better monitoring
• alerting that pings everyone immediatly in Slack (not emails)
• one-click revert

Theoretically, I'd ask seniors if someone's working on updating the code base before I jump into and work on whatever task I take.

I am not sure what's your point? Starting a new project from scratch, how to prevent generating legacy code? That would be following best practices, striving for clean code and minimalism, conceiving or using a good software architecture, writing tests right from the start (TDD if possible), naming variables and functions, adding useful comments (like JSDoc), preferring typed languages etc. and last but not least, as you said, documentation!

But maybe you mean how to deal with legacy code when joining an existing project? That's more common and worse in a way, but on the other hand, there is always someone else to blame at least before you have touched most lines of code sooner or later. Again, testing and documentation might help: is there documentation at all? Is it outdated? Does it still contain helpful information? Maybe it helps to understand the original intentions and requirements. Are there tests yet? If there aren't, we can start adding some simple tests while or before proceeding with our work.

Some other considerations: for the sake of consistency, we should probably align our new work with the existing code style and tools, even though they might be outdated from the current point of view. When everything has been written in ES3 JavaScript with spaced brackets and aligned equals signs, that's obviously the project's code style at the moment (and that's still the official WordPress recommendation right now, in 2023, as I found out recently).

And like Jean-Michel said, accepting that we are going to ship more bugs can help us to achieve anything at all.

Sometimes I start by creating unit tests of existing functionality and then creating unit tests for the feature I'm going to add.

What I'd like to do with legacy code

What usually happens:

It's a process.

1. Nail down a deployment process. It doesn't have to be the sleekest CD pipeline you've ever seen, but it has to be few enough manual steps that I can do it consistently without breaking things.
2. Deploy to QA and do user acceptance testing of the current codebase, by which I mean I want someone who is in a position to know who can verify that nobody has been sneaking changes into prod without putting them into version control. (I have been burned by this every single time.)
3. Start making tiny changes.

a. The first round, put in some comments. Deploy.

b. The second round, gently fix some indentation or formatting. Deploy.

c. The third round, rename some things to make them easier to read. Deploy.

d. The fourth round, start breaking up giant methods into smaller methods. Deploy.

e. Continue a-d until you have some methods small enough and pure enough to unit test. Deploy.

Now you have living code, and, hopefully, with each deployment, it goes a little smoother and quicker and becomes a little more automatic and a little less scary. Eventually you can build a pipeline with what you've learned.

I recently saw a talk given by Jason Blanchard at LeadDev NYC called "Everything is a Migration", and I think it helps out the concept of legacy code in perspective. The idea is that of viewing software and product development as an evolutionary process. In that lens, legacy code is just code, not a blight to be eliminated as some tend to think of it as.

Maybe it reflects an earlier set of priorities, if so evolve it like you would any code. Maybe the refactor is more intense, or more disruptive, but the process of migrating old code to new priorities is the same in spirit as all the work we do. If on the other hand it works and still fits the need, maybe leave it alone like you would any code that is good enough for the task at hand.

So I would say the way I'd handle it in any case shouldn't be fundamentally different than any other code you might find in a codebase

Define "legacy code". It isn't by definition bad; but of course it can be very bad indeed.

My first step would be to try and understand what it's doing so that, if changes are going to be required, I'm ready to make those changes. This might involve adding documentation where necessary.

If it's clearly bad code, or dependent on outdated technology (e.g. defunct libraries; difficult to manage build processes etc.); I would figure out a path to refactor it to remove that code and modernise where appropriate.

But sometimes "legacy code" is just fine. I know a site I worked on that is (at least the last time I checked) still running the script I wrote over ten years ago. I deliberately chose to use vanilla js with no dependencies (at the time most likely to be JQuery). I'm sure it could be modernized/improved; but apparently it still does the job well enough 😁

The common approach is to not invest in trying to understand the legacy code and to dismiss it's qualities. Management normally is happy to accept that and then allows ignoring it until replaced. Most of the time, that is an invalid, costly, sometimes fatal approach. Only after understanding the legacy code, one can tell whether it is any good or not. Write tests to cover it and to maintain it's proven functionality while cutting away parts that need to be replaced. The argument 'it is so bad, I can never understand it' is silly, it says more about the new programmer than about the old one.

working on legacy code is rarely nice. but can be a fundamental experience for devs at stage of the career at different levels ( I wrote about it some time ago in this post.

under a tight schedule can be very difficult, but the best strategy is really applying the boyscout rule, and add unit tests whenever you touch some lines of code.

fighting complexity and enthropy is a project is a constant effort, and if we lower our attention or give up because time is tight and code is already crap, we can only make the project and our live worse, at an even higher speed.