Approaching a New Codebase — Winning the War
So you’ve successfully breezed through the technical interview, and landed yourself your first job as a software developer, nice!
The first day is off to a great start, everyone seems pretty cool and the offices look amazing.
You even have a care package waiting for you at your desk, complete with a laptop, headphones, swag…all you could ever ask for.
You fire up your shiny new laptop, set up your local environment, clone the repos, and begin skimming through the company’s code with excitement.
A wave of confusion then hits, as you quickly begin to recognize deprecated libraries, functions with thousands of lines of code that seem rushed and the most convoluted folder structure you had ever seen.
Congratulations! You’ve just had your first interaction with the company’s codebase, a place full of wonder, bugs and surprises.
Let’s take a quick look at how you can tackle this unexpected turn of events head on.
Codebase — A Legacy
All of the code that anyone who’s ever worked for the company wrote, is right here in this codebase. This includes developers from different backgrounds, as well as a varying levels of experience and expertise — usually over a span of at least several years.
This code, mostly old, ancient and antiquitated, is the backbone of the company’s product, and it proudly goes by the name of ‘Legacy Code’.
It’s the result of years of adding and removing code, all while the technology rapidly develops, employees join and leave, and new coding guidelines and conventions are introduced.
And that’s actually fine.
One of the most important skills that you’ll have as a programmer is to get up close and personal with someone else’s code from 2 years ago. Back when the company only had 8 developers and an office in a problematic neighborhood’s back alley.
But don’t worry, your educational experience, whether it be college, a coding bootcamp or an online learning platform, will still be very useful!
The First Ticket
So you’ve been assigned to your first ticket and it actually seems pretty simple, great!
All you have to do is fix a small typos in the product’s settings page, which does sound easy enough. But…how do you get there? Where’s the code for the settings page?
You look around and find that there are four different modules named “Settings”, which fills you with hope — only to realize that none of them are relevant.
On paper it seems as if it’s a really quick and easy task that shouldn’t take more than 2 minutes, it’s only a typo after all. But in reality, you have to navigate through an unfamiliar codebase, something which you’ve probably never done before.
But don’t feel discouraged! That’s the real purpose of your first few tickets — navigating and getting to know the codebase. It’s perfectly fine if it takes time, even a long time, to fix that typo.
Don’t think of it as “It took me two days to fix a typo”, instead, know that the experience that you racked up in understanding the codebase was the real purpose of that typo.
Calling for backup
While trying to navigate this hellscape, you’ll most likely end up feeling completely lost.
Lost in a sea of wrappers, abstractions, enormous functions and old libraries.
Just ask for help!
Try to overcome being shy, let go of your ego and quell your competitive nature.
It might feel daunting at first, but asking for help and speaking to other developers is something that you’ll constantly be doing throughout your career — it’s literally a part of your job.
Sometimes you just don’t know what you don’t know. A case in which a quick session with a team member can ease your frustrations, and get you back on track.
This actually isn’t so bad
After several weeks, you’ll naturally get a feel for navigating the codebase. You’ll quickly recognize patterns, and all those wrappers and abstractions from earlier will become your playground.
You’re now a lot more confident and relaxed, you know exactly how to find that “Settings” page, and any page really. Several PRs have already been made, and you feel good…awesome.
What’s next?
Another ticket pops up, and you very quickly understand exactly what you have to do, and where to do it.
And then…a massive function appears, with creative variable names and countless side effects.
Fixing that bug could only require you to make a minor change at line 107 of the function, but…it just feels dirty.
You might feel an urge…the urge to refactor, to split the function up into smaller chunks, to rename the variables, to clean everything up, and maybe…just maybe…even add a test.
Hold up!
So you want to refactor legacy code
Don’t refactor just yet. After all, it’s only a very small bug which was estimated to be fixed by today. Are you sure you know what you’re getting yourself into?
Talk to your team lead. Let them know that you found what caused the bug and can fix it in a few minutes, but you would prefer to refactor the entire module while doing so.
Now, depending on the bug fix’s urgency, you’ll either be encouraged to begin refactoring, or be told that it’s currently not in the ticket’s scope.
That’s because refactoring legacy code could lead you down a rabbit hole, one which might be very difficult to climb out of due to its unpredictable nature and side effects.
Back to the Basics
So how do you get to a point where you actually feel comfortable with the codebase?
Utilize your IDE
Your development software is very powerful, use that to your advantage.
For example, VSCode comes with great tooling right out of the box, which could dramatically increase your code-finding skills
VSCode — Workspace
Creating a workspace in VSCode would give you access to all of the company’s Git repos at once. This lets you search through them all, without having to create additional windows.
All you have to do is create a “<name>.code-workspace” file in the same directory as all of your Git repositories, fill in the details and open it up with VSCode.
VSCode — Command palette
Hitting (ctrl/cmd + p) would open up the command palette, which lets you search the entire codebase for files, functions…anything really:
What makes this specific tool so powerful is that you could just “guess” a function name, which you think might be related to your bug, and VSCode’s search would find results as you’re typing.
Debug flows
Go ahead and place a breakpoint at the beginning of one of the product’s major flows, and go through the lines little by little.
This will help you understand how different modules speak with each other, and how they all relate to one another.
Identifying patterns
At the end of the day, someone intentionally created the folder structure the way that they did, it was most likely not done randomly.
There is a logic behind it, there’s probably a pattern that keeps repeating itself, which once realized, could make the entire file system feel like home.
What’s next?
Well, the fight is definitely not over yet.
Technology is still evolving, and employees are still joining and leaving. And for all we know, you’re probably currently writing the next generation of legacy code!
So with that in mind, try to be nice to your new codebase, it’ll definitely go a long way.
