Memorize the folder structure
This is probably the easiest and fastest thing to get you started. Source code is usually organized logically. By studying the folder structure, you quickly get a quick overview of how the programmer conceptualize the project. There are some popular folder structures that you might recognize. They will give you a hint on where you can look for.
Start from the entry point
Find the function where everything starts. Different languages have different conventions. For example in C and Java they start in the
main() function. For node.js you'll look at
package.json. For PHP it might be
Once you've found the entry point, you can start tracing the program flow. Look at what get initiated, or how the different modules are related.
Another starting point might be the request handler or event handler. That's where user inputs get processed. Tracing the flow there will help you map the code structure with the behaviour your get when you use the program.
Read the documentations
Don't skip the documentations! Some people just like to wing it or Google it when they run into problem. Reading the documentations first not only reduce the need to find help, it is a quick way to glance over the high level concepts, and to dive into technical details. The author has put a lot of effort into distilling their knowledge into something that can be understood easily by new comers. They often include complex logic that would take a much longer time to understand by code.
Read the test cases
Reading the test cases is very similar to tracing from the entry and reading the documentations. It provides a concise manner to see how the code is used and how it is supposed to work. One downside is the extra fluff that's need to run the test cases.
Use an IDE
Being able to quickly read the method documentations, view the file outline, and jump directly to definitions can greatly speed up the exploration process. If you're a text editor kind of guy or you've never used an IDE before, you should definitely give it a go.
Before you say "code should be self-documenting", hear me out. If the code is under version control (which it should be), then it doesn't matter what kind of monstrosity you do to it. You can always revert the changes. When reading through source code, use comments like how you would take notes on a textbook. No one might ever see it. You might be able to help improve the existing documentations too.