Getting Started on any codebase.
How to take on a new project or handle old codebase
If you’re a developer or engineer, you likely know that taking over a large codebase is nightmare fuel. Instead of suffering from angst over such a massive task, here are a few tips to help you navigate it.
First, accept that the codebase is a huge, clumsy, confusing mess of strings, literals, methods, functions, and calls to things you’ve never heard of. Yes, managing it is scary. You’re nervous, your managers are nervous, and, if you have a team, they’re nervous that you’re going to screw everything up.
Embrace that fear. Leaning into it is your best asset. We’ll explain. I will be sharing some great insight from research on how I have personally approached codebase from other senior engineers or colleagues
Schedule Meetings for review
Alright, so you are new to the codebase, you just joined or you were handed over the project. The best approach is to reach out to the engineer or developer already working on this project if he is around(still on the team), but probably if he is not around, then you can schedule a meeting with the project owner to walk you through the workflow to understand (what needs to be done, what is done, what is left) also you can reach out to the people who have been around the longest understand the code better than anyone (or at least they should).
Code is culture; understanding the code is a great way to understand the culture of the product, team, and company. If leadership has been in place for a long while, they’ll have tribal knowledge not stored in a wiki. Maybe there’s a style or methodology you can’t quite wrap your head around; they should be able to explain its inner workings. If there’s a direct purpose to things, those with the most seniority should be able to explain it to you.
And if there isn’t, and your new team lead takes the “it compiled so we shipped it” tone, then you know your job is simply to write code that works (somehow) and to do your best. Either way, your bosses will appreciate that you took the time straight away to wrap your head around your new role.
Seeing the code
Sometimes, it is overwhelming to see unstructured, no comments, and all codes written together in one file. What kind of developer was your predecessor? It doesn’t matter. You may be taking over spaghetti code, or their styling is so weird that you’re having trouble reading it. Or worse: they used tabs instead of spaces. You can blame your predecessor for aspects of the code, but that’s not a long-term strategy that will work out. At some point, you’ll be expected to understand how to read that wonky code, and how to write your own code that works seamlessly with the said codebase.
Remember, others may feel the same way about the code you write; the last person was just doing their job, too. However bad it is, don’t blame them for every delay or issue you have at work.
Please take your time.
In the office, there is frequently a sense of hurry. Refrain from doing so. When you rush into a fix, you’ll wind up with a broken product. The code you’re working with is one-of-a-kind, and it’s probably foreign to your way of thinking.
It’s better to try to understand what’s going on first before tackling major changes or upgrades. You must, in a sense, retrain your brain to accept and interpret this new code. You’ll have to shut it out as well if your tendency is to rewrite the code. A complete rewrite of the code is almost certainly impossible (or will require a massive time investment). While rewriting may turn out to be the best option, in the long run, you’ll almost likely have to persuade others.
Communicate effectively and timely
Having stood at your desk for a week or so, you’re still lost. The code isn’t commented on, and the file system is confusing. You’re a few hours into your cool new job, and you hate it. Talk it out. Now is not the time to tell your managers you hate your job (because you really don’t), but you should communicate your concerns.
Your issues may not be unique; it’s very possible your predecessor was toxic and defensive of their code and had no concern for anyone following in their footsteps. There are a ton of reasons you may not be grasping your job right away, but it’s always best to be proactive and tell your boss what’s going on. More often than not, they’ll find you the help you need, or give you the time necessary to do the job your way.
Get and Know your tools
Take time to know the languages, tools, versioning, and environment configuration for the project, and take full advantage of it. If there are APIs used, third-party services spend enough time going through and knowing them well.
It’s an easy way to get up and running with things like testing and debugging, which can help alleviate a ton of headaches.
This tactic works best when your company doesn’t currently have a favorite tool, or maybe looking for something better. By adopting some of these useful techniques, you can probably gain confidence in every codebase, to improve, refactor or build new features.
Read Approaching codebase itself (getting started on any codebase)