understanding a big codebase you have never worked.
If there is git history it’s often a good thing to use that to understand what tends to change together, which parts have lots of churn, etc.
There are tools for this: https://github.com/smontanari/code-forensics
I have two key points to understand any large codebase:
- Start with the entry point. Check the initialization process. It will most likely tell you what other parts of the code are crucial to the application. Start digging into those parts that are mentioned in the initialization process. Rinse and repeat for their dependencies which might look important. Just read and take notes if necessary. Try to understand how the application gets its stuff running. Don’t spend too much time on a specific part, just get a broad understanding and how it all flows.
- After the first step, you should start seeing some sort of patterns to how the software is made: repeating principles, common practices, overall architecture. This is the point when you should be confident enough to introduce changes to the software, therefore you should have a build environment which guarantees the application works. If it doesn’t, have someone in the team help you to get it running without any changes to the codebase. Don’t make changes until you have a working build environment.
With both done, you should already be comfortable enough to start modifying the application.
I cannot stress enough how many developers I’ve seen trying to dig into random parts of the code knowing nothing where or how it all begins, making it super-problematic to add new features. Yeah they can fix a bug or two, but the biggest issues start when they try to implement something new.
Get it up and running in a dev environment and start inserting changes to see what breaks where.
Revert and retry until you’ve learned where you’re supposed to be meddling.
Another big advantage of getting a dev environment setup is if you can get step by step debugging in place as well. You can then use that to follow the trail of a user action from the UI triggers all the way down.
Look at the packages. Try to break it down into architectural layers. Understand in a broad sense what each layer adds to the one before. Rage that it wasn’t so much architected as cobbled together from pieces never designed to fit together. Decry it as total garbage and recommend total rewrite.
As an advanced technique, you can usually skip the first half of this.
Yes, I’d start from “Rage”.
Everything except last 3 words.
Pick a small bug or feature from the backlog and fix it. First iteration of a fix is probably shoehorned in there, then I try to adapt the fix to the code base. Matching the style and design of the code base is more important than my own preferences.
I’m a learn by doing kind of person.
I think about a feature or bugfix that I want to work on, then shoehorn it in by any means necessary. Once my code is confirmed working, the planning phase begins and I go through the module(s) I’m working with line-by-line and match the original author’s coding style and usually by that point I pick up a trail or discover a bunch of helper functions/libraries that I can use to replace parts of my code, and continue from there.
As others have said, configuration files is a great way to learn that. Pick a config option you want to learn about, jump to the config loader, find where the variable gets set, then do a global search for that function. From there it starts to fall into place.
Sidenote: I also learned rust this way. It took me around 6 months to learn the rgit codebase solely from adding features that I wanted from cgit. Now I’m at the point where rebasing from upstream to my soft-fork doesn’t mess up any of my changes, and am able add or fix things with relative ease. If memory serves, a proper debugger (firedbg is excellent!) was used on several occasions to track down an extremely annoying and ambiguous error message that was due to rust’s trait system being a pain in my ass.
