How do you get to know an unfamiliar codebase if it has little documentation?

4 points·boppo1··6 comments

Suppose you're contributing to an open source project or just got a new job or you're modding Doom for the first time. Where do you get started in learning non-trivial software well enough to write new features or fix bugs?

View on HN

First, confirm its last-good build configuration (e.g., using Visual Studio on Windows for a desktop application), build it, then fuzz it forward and backward with other versions of the build toolchain (e.g., VS). This will certainly break it, as well as to expose points of fragility for troubleshooting.

100% agree with this. Read, model, then break it to find any incorrect assumptions you have made.

Another thing I haven't seen in this thread yet is that it just takes time. It takes time to grasp a system, and if it is a big project especially, you will probably still not understand everything after a few weeks.

Start from the simplest inputs and step through to figure out how the outputs are generated.

it's a very painful process. debugger is my friend.

Flamegraph is a bit useful https://github.com/brendangregg/FlameGraph

Read the source.

Of course. But where do you start? Just pic the first repository file containing code and work your way through? It seems to me like a person ought to identify some sort of 'central' file and work their way out.

Reply on news.ycombinator.com

How do *you* get to know an unfamiliar codebase if it has little documentation?

How do you get to know an unfamiliar codebase if it has little documentation?