What's the best way to become familiar with a

Question

Joining an existing team with a large codebase already in place can be daunting. What's the best approach;

• Broad; try to get a general overview of how everything links together, from the code
• Narrow; focus on small sections of code at a time, understanding how they work fully
• Pick a feature to develop and learn as you go along
• Try to gain insight from class diagrams and uml, if available (and up to date)
• Something else entirely?

I'm working on what is currently an approx 20k line C++ app & library (Edit: small in the grand scheme of things!). In industry I imagine you'd get an introduction by an experienced programmer. However if this is not the case, what can you do to start adding value as quickly as possible?

--
Summary of answers:

• Step through code in debug mode to see how it works
• Pair up with someone more familiar with the code base than you, taking turns to be the person coding and the person watching/discussing. Rotate partners amongst team members so knowledge gets spread around.
• Write unit tests. Start with an assertion of how you think code will work. If it turns out as you expected, you've probably understood the code. If not, you've got a puzzle to solve and or an enquiry to make. (Thanks Donal, this is a great answer)
• Go through existing unit tests for functional code, in a similar fashion to above
• Read UML, Doxygen generated class diagrams and other documentation to get a broad feel of the code.
• Make small edits or bug fixes, then gradually build up
• Keep notes, and don't jump in and start developing; it's more valuable to spend time understanding than to generate messy or inappropriate code.

this post is a partial duplicate of the-best-way-to-familiarize-yourself-with-an-inherited-codebase

Answer 1

One thing that I usually suggest to people that has not yet been mentioned is that it is important to become a competent user of the existing code base before you can be a developer. When new developers come into our large software project, I suggest that they spend time becoming expert users before diving in trying to work on the code.

Maybe that's obvious, but I have seen a lot of people try to jump into the code too quickly because they are eager to start making progress.