For the last eight months, I was working on a large .NETh project. There were three main repositories to learn, and each had its own complexities and nuances. It was a struggle to ramp in and even more difficult to complete feature work. I was lost constantly and strained to find where I was supposed to add code. It turns out that understanding the business rules wasn’t any easier.
If you are becoming frustrated finding where to place a feature, struggling to navigate a large codebase, or having difficulty understanding the domain, you are not alone! Here are my takeaways from my experience!
Where do I implement my feature?
If you are anything like me, finding where to implement a feature is always a challenge.
“Start at the root and end at the leaf.” I can still hear that adage in my ears like the first time my tech lead said it to me. It is extremely helpful to “follow” data through the project when struggling to find where to place a feature.
Locate the part of the project where you would expect data to enter the system. Then go through the code as if you were the data being processed. As you follow the data through the system, it’ll be easier to find code similar to the feature you are working on. Then, hopefully, you’ll be able to recognize the place to add your implementation.
Another trick is to find the “layer” at which to implement the code. Hopefully, the project is built into layers where certain types of features will exist. You should think about groups of similar functionality like: database connections, controllers, UIs, services, etc. Being able to classify the work should help guide you to where the implementation should go.
How do I find my way around the project?
Experienced devs seem to walk through a project the way I might walk down the street, but when I first got on the project I had a lot of trouble getting my bearings.
It might sound simple, but a great starting point to finding your way around a project is by searching key terms. I would search for an “OrganizationManager” if I wanted to find something that managed an organization. Retrieving a set of organizations from a server might look like a GET endpoint called “getOrganizations”. I’d search the project for a function called “parseOrganization” to find a method that parsed data from a database into an “Organization” type. If you can’t seem to find a key term, try finding code similar to the code you are looking for. If you are looking for a model, try to find the place in the project where all models are kept!
Another helpful tool for understanding the project is to look at the endpoints. You can see where data enters and exits the system, the shape the data takes, and sometimes permissions surrounding that endpoint. Understanding the endpoints of the project can help you better understand the software and help you navigate through the code.
If you are still lost, “Start at the root and end at the leaf.”
I don’t understand these business rules!
There will be times you’ll do feature work where you are uncertain of what the business logic should be, or the story is going to be missing details. The best thing to do in this situation is to reach out and ask. Your leads, manager, or product owner will be more than happy to sit down and help you solidify your understanding and implementation of the feature. You can continue to grow your understanding of the project, and (bonus) you’ll look good in front of your leads!
It is good practice to just ask questions in general. Whether it’s reaching out to a designer for feedback on an implementation or asking the product owner for business information, questions are always a great way to better understand the project and provide more value.
Those were my big takeaways from my first large project! What helpful hints do you have for people new to large, corporate projects?