The one thing that you would never want to do is actually read through the code line by line*. HOWEVER, let it be noted that I mean this as an initial point of insertion. As a Computer Scientist, your first step should be in attempting to ask the right questions.
Think of it like a game of 20 questions ( N questions in this case...). To do this, one of the best things I have done is to follow the process. All distributed systems attempt to solve one or several use cases. Define these use cases and then analyze the code basis from there. For example, a use case that involves a REST Endpoint can be updated your profile photo. The use case would define a point of entry (where/how to submit a new photo) and a point of submission (the REST Endpoint). From this, we can search for two components in the system that facilitate this task.
=== A good word of advice in understanding any code base is that, nine times out of 10, it is ALWAYS easier to read code once you understand its purpose. ===
> Language Specific Strategies
As for some good language specific strategies, be knowledgeable of what Paradigm the language falls into. For example, Java code tends to have a single point of entry for most cases. Whereas Javascript (as a functional language) can have several entry points (or even none at all). For functional languages, be mindful of how they are structured. Functional languages are not object-oriented by nature but they can be if implemented properly. As such, try to notice the key differences (i.e. prototyping).
> Cloud Debugging?
I would not consider it. Debugging should be a constant process of development. Not even the best developers can write perfect code from the start but with enough work and constant QA testing/Unit testing during the development process, any code base can become easily manageable for debugging. In addition, learning how to read Stack Traces can save HOURS of debugging.
> Tracking knowledge from Module to Module
Personally, I keep notes. I pretend as if I am writing an API document. Nine times out of ten, most modules take an input and provide an output after some calculation. So long as the calculation is sound, I do not worry about the calculation and only record the call to the module itself and its return. Other cases like classes can be tracked by the same notion.
> OH THE COMPLEXITY
It's a necessary evil. No one ever said being a developer was easy. And no one ever said the best things in life are free and easy. I work hard for what I do and for what I want. I love my job. I don't think I would ever consider changing careers. Sometimes the complexity does become overwhelming and its hard to handle. But if you wish to know my little secret, schedule yourself some mandatory free time. And stick to the schedule. This doesn't mean try breaking away from the computer, but just do things that help you relieve stress. Talk to a friend and have a drink or two. Developing is tough on the mind but it is an occupational hazard in the least.
> Updating/Maintenance
If it's open source, let the users dictate when the updates should happen. I believe in Agile development and trusting the users. But when it comes to updates and maintenance on a corporate system, always try and set some goals for the change. Why are you updating/performing maintenance? Is it to improve the speed/response time? Is it worth the cost of time/labor?
> GOLDEN RULE: Ask Questions. Be Skeptical and always tread carefully. We are Developers. We are Problem Solvers. Not Problem Makers.
BG: I have 6 years of experience working with Corporate level architectures and distributed systems. And earned my BA in CS minor in Information Systems. In my time, I have worked with multiple functional, object-oriented, and web based languages. I have also worked as a Full-Stack Developer for roughly 3 years now.