The title says it all, but I'm curious to find methods that people use that I never thought about. Considering my relatively short history with development, I've never had to deal with massive code bases.
What sort of things do you do to get familiar with a large, complex, code base as fast as you can to be effective?
jump into the code. the docs are almost always out of date/incorrect.
I like to run through some QA test scripts (assuming they have them). I follow that with a review of training materials if available and any high level design documents from the last release (if there's been one). Then I like to check out any available data dictionary and finally it's into the code via a local running instance of the application and the debugger :)
That is, of course, assuming you have the time for all of that.
If there are unit tests, look at those first to get a rough idea of how the components work. Next, feel free to add your own to get validate your assumptions of how you think things work.
Go through the code and apply the "Boyscout Rule" where you leave it better than you found it. Clean it up using techniques found in Clean Code by Uncle Bob. Cleaning things up forces you to understand it to some degree.
This is something I often struggle with, so I'm looking forward to hearing what people say.
My first thoughts:
Pick a problem ticket and learn what you need to fix that one issue. The next time, pick a different issue, but one that builds on what you already know. As you solve issues one at a time, your knowledge will expand. Soon you'll understand their coding standards and the basic arch. of the application enough to seamlessly add features from scratch.
Run the code attached to a debugger. That way you can see the code in action and if you want to know specific implementation details, you can drop in some breakpoints and step through the code line by line.
Knowing the end result of the code can better help you derive intent. And knowing the intent will allow you to understand the entire project better.
I don't think there's any magic bullet for it -- it just takes time. Also it's not necessary to understand every piece of a code base to be effective in working on it. I find that the majority of the code I work on is filled with helper classes, and the high-level application logic is actually pretty small.
As others said, pick out some outstanding bugs to fix and you'll learn a lot in a hurry. (Start with simple ones like "change label text from A to B" instead of "switch from using a relational database to an object database.")
first understand what the system is supposed to do, in business/solution terms. It will do you know good to understand the code inside-out if you are not familiar with the problem it is intended to solve
after that, then pick the smallest module that performs some useful identifiable business function, or read the doc (lol), or read the unit tests (roflmao), or read the code bottom-up. The first two rarely exist, the latter must exist