Ask HN: What tools do you use to familiarize yourself with a new codebase?
Sometimes a codebase has sparse documentation, or the maintainers are too busy to answer questions regularly. This is especially true for open-source projects.
When looking over a large codebase with poor documentation, what tools and tricks have you learned to understand it faster/more easily?
Examples can be language, platform or IDE-specific, e.g. "projects on github have a handy search in project feature!" - Never aimlessly browse through large codebase. Pick a change you want to introduce, maybe a string change, a small bugfix, low hanging feature etc. Goal gives you the motivation to keep digging through things and in that process you make a good mental model of the codebase. - Sprinkle logging statements all over the place and tail logs to figure out the execution flow. - Look at the past merge requests. They typically have descriptions. Go through the ones where you have some context about the goal of MR. For C# codebases that have no documentation I use a script that has evolved over the years that generates a private documentation collection for myself. It scans for static methods and data access classes using reflection and dumps their signature/return & parameter information into a documentation template. That way I can see what exits to leverage when adding new features - having spent way too much time over the years listening to 'why didn't you leverage this?' in code reviews. I'm currently working on a new one that scans for stored procs in databases to see what's living in the dark down there. I think understanding a code base should be an interactive process, because software's static form, i.e. its source code is different from its dynamic form when it's loaded into memory and runs. And it's really the later we want to understand. So the key tool should be a debugger, windbg , gdb. Other than that, grep, find, opengrok are good tools. If you're not using an IDE or a text editor with "go to definition" feature you really should be. Might sound obvious but it will change your life if you're not already using this. Check out the unit tests around the parts that are interesting and dig into the codebase from there understanding how things are used from the tests. I'm using atom.io plus grep plus find. Also found reading code directly from github quite comfortable.