this post was submitted on 07 Jun 2024
2 points (100.0% liked)

Experienced Devs

4275 readers
1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

founded 2 years ago
MODERATORS
 

understanding a big codebase you have never worked.

top 6 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 10 months ago (1 children)

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.

[–] [email protected] 2 points 10 months ago (1 children)

As an advanced technique, you can usually skip the first half of this.

[–] [email protected] 1 points 10 months ago

Everything except last 3 words.

[–] [email protected] 1 points 10 months ago

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.

[–] [email protected] 0 points 10 months ago (1 children)

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.

[–] [email protected] 1 points 10 months ago

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.