Initially, you don't need to understand every line of code.
Borrow a senior developer for a half-hour and ask him to give you the birds-eye view of the architecture - what the major blocks of code are, how they interact, and how the user / usage drives data through the system.
Then spend some time investigating the source for the modules you feel (after the explanation) will give you the best insight into "how it all works".
I have a (probably quite odd) habit of printing out large blocks of sourcecode, and covering a floor with the printouts. Then I can kneel down and crawl around on the floor with a pen and literally draw arrows from point to point, and draw around sections - I find that displaying code in 2D makes it easier to figure things out. It also enables making copious notes that help me understand the flow in more detail.
Before long, you'll start to recognise idioms (stylised ways of doing things) that characterise the code, and eventually you'll find your way into the mindset of the authors.
Then everything will be a lot simpler.
While you're on the floor, crawling around, have a laptop+google handy, so you can decipher anything odd you encounter. Also: Coloured highlighter pens FTW.
Make (at least) two passes at understanding the source.
The first time don't try to understand any of the minutiae... try to get a feel for "movement" - where data goes, and where execution goes. That will give you a framework for your mental model of the code. When you go through next time, you can start to break down details, but a top-down approach always makes things easier for me.
If you're not familiar with the technologies, language or environment, then do see if there are any books around you can grab. There's a lot more visible space in the real world than you can fit on a computer screen, and having google on a laptop, syntax/library references in a book, and the code all around you makes (for me at least) the whole process VASTLY simpler.