HN Explorer

Ask HN: How to efficiently learn a codebase new job that has no documentation?

4 points by virtuexru ↗ HN
So I'm in a bit of a pickle, I've started a new job and am trying to get "familiar" with the code over the holidays while most people are away. Unfortunately there is absolutely zero documentation. The codebase is massive and spanning across multiple repositories. I want to dive in and be productive as soon as I possibly can. Outside of code pairing with the the other developers (which is currently impractical due to most people being on vacation), what is the best way to approach learning the codebase at a high level (and eventually granular) so that I can make an impact ASAP?

2 comments

[ 1.1 ms ] story [ 10.7 ms ] thread
davismwfl
Pick use cases and walk through the code. I usually start with something simple like login, or common functions like logging etc. Use case focused lets you see the app in use and then trace what the code is doing which to me is far more valuable than just reading code. Reading code without a purpose is useless IMO. Also doing this is sometimes great for the team because you will find stuff they have missed and can ask questions about it which will result in either them explaining why it is that way or saying crap, good find.

Other options (I usually use these to build documentation from a codebase I don't know but to get up to speed faster I use the above method):

If it is object oriented, find all the base classes and work your way up through the derived classes learning what they do. Once complete, follow the procedural method below.

If it is procedural, then find the entry point and walk line by line, and at the first non-system/sdk level function call start building a function map so you know what calls what and what data is needed, passed etc.

no-s
this is a good strategy. You want to understand the flow, and discover what is important to accomplish particular use cases. This should also tell you about interfaces, which helps with divide-and-conquer against the code base. You also want to be able to reproduce builds and configurations, so you need to identify the related parts for a particular component.

Tactically reading code may not seem productive, but if the source is versioned and someone has explained the history of the application, you might be able to pull diffs and see what code was the target of changes, thus telling you what is the focus of attention. Code that isn't changed very much but is used a lot tells you what are truly fundamental parts of the overall systems. Commits may help with identifying who to ask about a particular section. Perhaps the committer might have or be able to identify some relevant documentation relating to their specific work. The build can tell you about the relevant part of the code base in use as well. Often an org may have documentation, but the docs may not be well indexed. Running code is the index.

I'm "experienced" and get kinda curmudgeonly ( or worse ) when I work someplace that runs the developer shop like it's 1999 or earlier, so I'm always vigilant for anti-patterns in the interview...the situation the OP describes would be one of those - if job position is not "heroic individual contributor" I would expect some sensible on-boarding for new devs supervised by a knowledgeable guide, with some example tasks to help get up to speed. Successful orgs do this. Orgs that don't are prone to failure and devaluing your shares through repeated VC financing, heheh.