TLDR; Divide-and-conquer heuristic.
When I was contracting, every few months I was looking at a new-to-me code base. First - if you don't know the language the code was written in, then you need to learn that at some basic level. Next, if there was some framework or set of libraries involved, see how many of those you can identify and how many you might already know. Start with trying to run through a build, as you'll either have success or it will throw errors and that will teach you something about both the health and the components of the project.
Once you actually get into the codebase, look for patterns. Often there will be pretty clear layers or types of components, identifiable either by name or organizational structure. Sometimes you'll see patterns that tell you "Oh, George must have written all this code, and Steve must have written all that code" because of personal idiosyncrasies. That's the worst case, but sometimes it's what you have to go on.
I spent a lot of years in application triage, where I was called in to fix serious problems in apps with which I had no experience. Like today's Apple outage - I used to parachute into situations like that and had to get things running, fix, post-mortem, etc. There are great tools out there where you can inject them into running code and watch real / test users execute code. Thats's a great way to very quickly learn how everything is assembled, IE: why did that piece of code get executed there, or why didn't that piece of code get executed.