Here's how I tackle it:<p>- if there's good unit tests, I immediately feel more comfortable and confident as nothing can explain the code and behaviour more than the test suit.<p>- if there's no Tests, but can allocate sometime to think and write tests. that's the best documentation you'll ever provide and benefit from.<p>- With better languages debuggers things are easier, logging to the console keeps to make me win quicker in some cases!<p>- Really long comments are confusing sometimes. and might make things more complicated than simple.<p>- Time will help you get everything. The more time you allocate to focus on the codebase you'll find yourself more familiar. If you have time, make sure you don't stress yourself and stare at it too long. take breaks do other things and come back to it once you brain is cleared.<p>- before you build on top: Once you understand most the ins and outs, try to burn down bugs before building on top.<p>finally - it is OK if you don't know 100% of the code. no one can easily know a whole code base they didn't write!
I guess it really depends.<p>On projects where the level of commenting is low and theirs little to no documentation it can be tough.<p>For C projects as there's usually a single point of entry I just start with main() and read through the code to get a conceptual overview of what's happening. Often I find it useful to comment the code/write basic documentation as I go.<p>Then I often attempt small changes/refactoring to attempt to validate my understanding. Often I'll add code to dump intermediate data to better understand what's happening.<p>It can be quite a slow process in a large project to be honest, and it's a lot easier if you have the original developer available to ask questions.
You might be interested in this discussion from a few days ago: <a href="https://news.ycombinator.com/item?id=13282756" rel="nofollow">https://news.ycombinator.com/item?id=13282756</a>