Today I'd like to talk about how I approach the giant code base that I work on in an effective way.
We're a large supply chain IT consulting firm that works on various products that allows retailers to optimize their supply chains in various ways like their e-commerce presence, order management systems, inventory management systems, etc. And without boring you with a lot of detail that I'm probably not legally allowed to divulge, we create and maintain different API's and have multiple services running through them, along with different platforms we interface with, so there's a lot going on.
Needless to say my first few days were ROUGH. I was confronted with a giant codebase that didn't make any sense to me whatsoever, but once I decided to break down how I wanted to understand what was going on with a little help from senior engineers, things started to come together pretty clearly without even pulling a single repo down, here's how I approached the problem of a GIANT code base at work.
- I took the time to ask a senior engineer how our database services worked together and how our data flows.
There are a few database and caching services we use that server their own purposes to optimize the way that we move data, and understanding how data moves is one of, if not then most important thing when trying to understand how the product(s) you'll be working on actually works. Getting a high level overview of what our endpoints hit, where did logging information go, as well as where consistently requested data was being cached was SUPER important in building my understanding. It only took about 20 or so minutes of an explanation from an experienced engineer to lay it out for me and Iw asked away with invaluable knowledge that would've easily taken me hours to learn on my own.
- I took notes and really tried to understand how the development and quality assurance environments are set up.
Underneath complexity lies many simple concepts that underpin it. Going through the set up of the development environment in a measured way can help you really understand what's going on. More than likely if there are multiple repositories within a giant code base, they are connected in some way. Take the time to understand how they link together when you are setting up your environment, you will definitely uncover some great things about the code base you would not have otherwise found out by looking at each repository separately.
- Here is where I started to pull down repos. I explored the program myself and observed API endpoints within the browser inspector.
This is an INCREDIBLY important thing to do that seems obvious, but to a new engineer I'm sure the sheer size of a code base can seem overwhelming, and it might not come to mind to just play around with the application itself. Keeping an eye on the network tab and filtering to only seeing the JavaScript functionality was really helpful in understanding which endpoints were being hit and when. Observing the body and parameters of responses and requests are key to building your knowledge base of an API you are working on. Once you hit an endpoint, you can reference it within the code base of the API itself and follow the path to perhaps the middleware it uses in validation, the database interaction, or any other inner workings of the API. The web browser inspector is a powerful tool and will be your right-hand in your web development career!
As I've grown as an engineer, I continue to use these techniques. My understanding grows day by day, and I'm very grateful to the team that I'm on that are ready to give advice and help out when asked. With these tips and others that I plan to share going forward, I hope aspiring and new engineers like myself can take these tips and apply them effectively.
Thanks for reading...till next time!
Latest comments (1)
Having a good technical documentation helps too! First read documentation, if there's any doubt ask the senior engineer who will answer and update the documentation. :-)