My question is pretty straightforward: how do you, hacker news enthusiast, familiarize yourself with a new codebase? Obviously your answer is going to be contingent on the kind of work that you do. Some background: What's motivating me to ask is that I am flirting with the idea of trying to add a couple of features to SlickGrid (https://github.com/mleibman/SlickGrid), Michael Leibman's phenomenal javascript grid widget. Unfortunately Leibman got busy and isn't actively supporting it anymore. The codebase is something like 8k lines of javascript, so it's not ludicrously big, but I'm kind of intimidated thinking about trying to make sense of it. My first strategy is just to open up important-looking javascript files (slick.core.js, slick.grid.js) and read through for comprehension. This seems like a pretty slow way to build a mental model of the code, though. Some features I want to implement are 1. an ajax data source that doesn't require paging, and 2. frozen columns. Someone else has implemented a buggy version of frozen columns (and since abandoned the project), and I might like to use it, but I can't tell if it's buggy because it's a hard problem, or because their implementation strategy was poor (or both!). So at the moment I can't evaluate if I should implement my own, or try to fix the issues with theirs. Picking up other people's code seems to be one of the harder tasks developers face, as evidenced by how much code gets abandoned, so I wondered if the voices of experience on here could point me in the right direction, either by talking about this problem in particular, or more generally, how you build knowledge about a new codebase. Thanks! |
There was a previous discussion here on HN that covered this in depth. You may find it interesting:
https://news.ycombinator.com/item?id=9784008
In short, top-voted strategies include:
- Try to find out "hotspots" in code using some scripting (e.g. https://github.com/gilesbowkett/rewind). According to user tessierashpool on the last thread:
> we tend to view files in a list, but in reality, some files are very central, some files are out on the periphery and only interact with a few other files
So, finding out where most things happen in the project is a good way to get up to speed.
- "Deep-diving": starting from a high-level point (say, the moment you type ssh-keygen on your terminal), go down the subroutine rabbit hole. You're likely to cover a lot of ground this way.
But really, read the previous discussion, many many great strategies shared - many of which I already used before reading that discussion and some I've incorporated since.