Code Spelunking
Alex Miller writes about code spelunking techniques for when you’re digesting someone else’s code. He offers some good advice, particularly for tracking down call hierarchies and implementors (and some useful Eclipse shortcuts). What was missing, I thought, was the easiest one of all:
Draw a picture.
He did show a project dependency graph, but I find it’s really best to draw a simple picture, not even in UML, just in whatever comes naturally to you. On this picture, keep the real names of the classes, but then give them useful names, or small summaries, and describe their general responsibilities.
Use this diagram as your map, and don’t complete it for perfectionism, but only follow interesting paths. Invariably you’ll end up pruning paths as it’s clear that it leads to property holders, or utility functions (which is part of classifying the objects, as Alex writes) in which you’re not interested. But in particular, when you draw your own diagram, you have a bread crumb trail to look back on, so when the names don’t make sense, or you can’t remember the big picture, you’ve got your notes of what you’ve already seen.
Besides, if you’re drawing a picture, then the next developer who comes along will need to draw a picture too. So you might be able to do a formal diagram and put it into the project, helping others pick up on the architecture that much faster.