Taking on a task in a monolithic codebase can be daunting for developers who are new to a project. If you’re unfamiliar with the term, a monolithic codebase is a very large application that is tightly coupled. There could be thousands of files and commits, and many teams contributing to the same codebase. At first glance, it may be hard to understand how all the pieces are working together without knowing some more context. Let’s take a look at a few ways in which you can start to grasp a monolithic codebase.
Read the Documentation
The first place I start with a new project is reading over any available documentation or README files. This allows me to become familiar with the setup, functions, style, and other important parts of the codebase. Some parts of the documentation might be out of date, but seeing the evolution of code can also help to understand the project’s history.
Read the Commit Messages
Reading over commit messages for a particular file in which you are working could help you understand the existing code. From the commit history, you might be able to find a pull request that has further detail on any changes and on the developer that made them. If that developer is still on the project, you may be able to ask them some questions about their code.
Pairing
A great way to gain knowledge of a project when starting out is to pair with a developer on your team who is more familiar with the codebase. This person can provide high-level insight about particular design patterns, testing, processes, and third-party code that are relevant to the project. They can also give you more historical context about the project and why certain choices were originally made. If you feel inclined, take this new knowledge and add it to the project’s shared documentation—it will help make onboarding other new developers in the future much faster.
Read the Tests
Look to see if your project has unit, integration, or functional tests. Run the tests and look over what each one is doing. Reading over the tests for what I’m working on helps to get a sense of the functionality and any edge cases or defects.
Start with the Smallest Part
When I’m trying to read JavaScript that someone else wrote, I look at a line of code in the file that I already understand. From there, I keep moving to figure out the related lines of code that I don’t know so that, eventually, I can make sense of the entire piece.
I also like to take a step back to see how a file is being generated, then try to understand the code that is generating it. For example, I will trace back to the import statements in a React file and analyze what a function is doing, or I will go over each part of an npm script that is generating a compiled CSS file.
Dive In
Each of these approaches can help you get started and not be overwhelmed by the size of the monolithic codebase. With time and patience, you will become more familiar with the codebase and reading others’ code will get easier and easier.
Sparkbox’s Development Capabilities Assessment
Struggle to deliver quality software sustainably for the business? Give your development organization research-backed direction on improving practices. Simply answer a few questions to generate a customized, confidential report addressing your challenges.
