Developers/Students who are new to Open source usually get overwhelmed by the huge codebase. In this particular blog, I will be giving some tips on how to Approach a Codebase(The right way). And I learned this from Rahul Pandey from CS Dojo's podcast.
Before talking about the approach to read a codebase, let's understand why contributing to open source is necessary for any developer in the first place. As we all know when a Software Developer gets a job at a company, after joining the company the first thing that the developer has to do is to read the existing codebase of that particular company. And if that person doesn't know the right way to approach the codebase, he/she might get burned out and feel like giving up. Or the worst case would be he/she won't be able to survive in the Tech world.
Here's where open source helps you before getting into that trouble. Before joining a company or a startup, we should start contributing to open source projects. There are 100+ beginner friendly Open source projects & organizations on Github & GSoC (Here's the link: Open source).
Now, the most common issue that a student/developer face while trying to contribute to an Open source project is difficulty in reading or going through the codebase.
The Right way to start Contributing✅
Start running the ASAP
The number one biggest thing that a person can do is start running the code as soon as possible and this might sound obvious but this is a crucial step to start off. And what you should not do is think "let me spend the next week reading the code and try to understand it in my head and then I'll run it and it'll make a lot of sense to me" but that never works. The way you understand the code is by writing the code and then modifying it (which is what we'll talk about in the next step). The other thing is when I talk about running the code I also mean like make any change so that you can actually see a result. So like what I mean is like "I'm going to add a log statement", "I'm going to put a breakpoint somewhere and I'm going to see that breakpoint get hit", or start making some minor or major changes that are visible. If you can do that you're already halfway through in terms of understanding the new code base. But what you shouldn't do is like read the code in isolation and hope that it'll magically make sense to you, that almost never works especially working with any big companies' codebases.
Intentionally break things and then understand How they broke
Before you make your change you have to understand the current state of the logic, if you don't understand the way things are working then how could you possibly make a change to make it better?
Land a low-effort code change quickly
Okay so the idea here is that, another really common failure made is that people think that they understand the project (which is good) and then they say "let me make some changes right now" and then they'll basically come up with a code change which is like 500 lines and then they expect all the people on that team to already understand it and review it, and that's a big mistake because I think for two reasons it's a big mistake,
At these big companies where you have these large codebases, a big part of landing code is actually gaining the trust, and let's say you've never worked in my code before and you basically made a big change and now you're expecting me to review it, basically came out of nowhere & made this big change and now you are expecting me to understand it and review it without giving me much context or without gaining my trust yet.
Often times things will happen in the process of making the code change that will be unexpected for you and so my recommendation for everyone is that, don't care how small the contribution is if it's just like adding a comment to a random place in the file make that code change right now and land it.
Understand the code hotspots
So the idea here is basically that when you enter into a company like Google, Facebook, Microsoft these are companies that have tons and tons of developers and they've been around for a decade or more, and so there are going to be large parts of the code base which are dormant and what I mean by that is basically they're going to be large parts of the code base that no one really understands or no one has touched in years. My advice would be, generally if you're new in the team you're not going to be making a change in one of those dormant parts of the codebase, typically people will be making a change in the area of the code which has already been actively being changed. I would recommend you all to understand where are people actually making changes on the code and so tactically the way you do that is by looking at the updated files or there are many tools in local IDE(vscode) that helps us to understand where & when the changes has been made.
If you just follow these simple steps, I'm sure you are ahead of most of the new contributors. Also, the most common mistake a new contributor makes is that, most of them don't read the README file or just read the half of them or just views the website of that project(in case if you are contributing to a web-based project).
Finally if you have read all this and really understood what I was trying saying then you did a great job and I'm sure you gonna make it🚀.