This one came from Slack.  I answered it briefly there, and so did other community members.  But, I thought it’d be a great idea to dig into the topic a little more here.

“Does anyone have any advice they wish they knew before jumping into a legacy code base?”

Before asking for help, ask if there are any ‘gotchas’ in the code that have to do with your ticket.

Sometimes the code you think you’ll have to work in to solve a problem isn’t used by anyone anymore.  It hasn’t been removed because no one is sure what will happen if you deleted it.  Or, sometimes a small change in the code that you’re working on may result in breaking code somewhere else.  It could be that this is part of the shared knowledge between existing engineers on your team.  But you’re the new kid on the block, or haven’t worked in that part of the code base yet, so you don’t have that knowledge.  It’s better to find out before you work on a fix, write tests, attempt to refactor and submit a pull request.    Other times there is someone doing a big refactor on part of the legacy code base, so you’ll need to coordinate with that person.  But you won’t know unless you ask.

Take Lots of Breaks.

Working in a legacy code base takes more time and energy.  Often times, you’ll have to explore parts of the code that were created on older versions of technologies that you aren’t familiar with.  Also, the code may be written in a way that is difficult to reason about, which adds to the cognitive load.  When I started thinking of working in a legacy code base as more of a sprint, not a marathon, I was able to fix bugs faster.

I also made this fun video about working in legacy code bases:




%d bloggers like this: