How Do You Understand a Complex Code Base?

Spelunking. A lot of code spelunking. I have been doing that for a lot of years. I like going through other people’s code to understand how they do things. This is why I love open source software.
The best approach to becoming good at spelunking is by starting small in a known environment. Pick a small, well established framework. Set a goal, a thing you want to understand how it is achieved. Then start at the bottom and try to find the path to your goal.

For example. For a small CMS framework. Try to understand what is done to eventually render a page. Or how the plugin/module system ties into it.

Do this once in a while. After a while you become good enough to take on bigger frameworks or more complex goals. Don’t stick to the same framework. Spelunk different code bases.

Eventually you will be good enough to simply dive into large complex systems. You will have developed the skill to know which paths you probably don’t have to take. You know how to keep around relevant contexts.

I’m sure there are articles and books about this. But the best is simply by doing it, often.

I usually try to write some unit tests to confirm my theories about a particular chunk of functionality or component.
If the project doesn't have previous unit tests, what always almost happen, is that the architecture and dependencies will not allow you to write the tests, but I learn a lot trying to do it.

It depends

If the system is live and broken for some case (maybe there was an update to a dependency that went badly) AND if it using a scripting language that you can alter then putting in tracing all over the place is quite good

The one thing to look out for is coupling through multiple channels.
For example, program A is supposed to talk to program B via a REST API. But hey, look they are on the same machine so some genius made them both share state via a file!

That kind of thing happens all the time and makes it difficult to understand emergent behaviour

Depends.
See if can isolate the component and find the dependencies.
Is there a design pattern being used?
How are the interfaces or abstractions used?
Isolate inputs and outputs.
Ask yourself, if this component was taken out, how would the overall application work?
Just a few hints, and yes Google is your friend :)

This is what I did when I started this gig that I am currently in.

• I usually not try to understand everything, each component, because it makes me anxious. What I usually do is to ask for an small task (I.e. resolving a bug or changing a small part of UI, if you are doing front end or mobile) and I try to use that as a guide to star learning the code. Then, I ask for a different issue, that maybe solves something in another part of the code base.

• I use notion to make some notes about what I am learning and try to compare and contrast with my previous projects, because that makes me think about why some things are different. “My previous project used MVP as a design pattern, the new one uses coordinators. Why?”. I write that down and start to research about the motives. At some point, I can ask somebody to resolve some doubts.