Ask HN: How do you get started on a code base?
What are some tricks and methods you use when you are getting yourself familiar with a new code base? How do you shorten the learning curve?
"Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won't usually need your [code]; it'll be obvious."
https://hw.leftium.com/#/item/10293795
---
Also I find opening a project in VS code makes browsing/searching through it much easier with features like:
- F12 to jump to definition/references
- Shift-F global project search
One problem you might face if the codebase is really old, are the multitude of styles and patterns that exist in different areas of the project. For those, it’s good to start in one area, and slowly reach out to other areas over time.
--EDIT-- Thinking about this some more, here are some other tips: First and foremost - remember Chesterton's Fence. If you see something that looks strange and unnecessary - don't remove it, it might be load bearing! Also, if you are working in an IDE that has a step-through debugger (common in C#, Java, and others), then set an early breakpoint for an API call and follow it all the way down the rabbit hole...you'll see things happening that you never would have found by manually poking around source.
Every time you need to learn a subsystem of the codebase, the same concept applies. Learning the shading language compiler? Well, learn the shading language itself and then learn the Hardware's programming interface for shaders. Learning memory management? Learn how programs manage their memory, learn how the hardware managers memory. And so on.
Want to dive into a library? Well, learn how to use the library. Then learn whatever interface the library is on top of. Then imagine how you would implement the library yourself, that should give you a gigantic idea of how the library works and you would probably start recognizing what each piece of the code does.
Also, ctags, cscope and Vim's ctrl+] are essential.
As for understanding code, deep dives, fix bugs, try to write a feature. After doing a number of these you start to get a picture of some details, characteristics of the programming style, and start making connections at higher levels.
"What does the business do, what do the users care about, and what value does this system add for those users?"
"What 'things' does this system involve?" Print out the DB schema + classes to see all of the entities represented in the system.
"What are the things this system does?" Read the unit tests. They describe the intended behavior + the minimal context required for that behavior.
"How do I see output for the changes I make when I work?" Ask a few of the other devs what their feedback loop looks like during development.
Then I make a copy of the repo and comment the shit out of it for myself. I summarize the existing code, and include any observations, thoughts, whatever.
One more: I keep a text file with a list of "activating questions" prior to any of this, which I continually add to, and write answers in. I use this to batch inquiries for other devs, who I set up 20-minute sessions with to answer my questions, so I don't pepper them continually with interruptions.
I turn a new-to-me codebase into a literate program using org-mode, creating all the links I need and documenting as I go (since most systems are grossly underdocumented). Writing tests and using a debugger/tracer/whatever to follow the executable's flow. I have git ignore the .org files and periodically tangle the source files to ensure I haven't introduced unintended changes (as seen using git diff). The org files are for me, and I turn them into documentation for other people if the whole team is new to a system (like when it transfers from one org to another for whatever reason).
I don't think there's really any way to shorten the curve, but this has the effect of focusing my efforts at understanding. Previously I'd just poke about haphazardly, turns out that's too unfocused to be effective for me. It leads to a narrow understanding of the system instead of the desired broad understanding of it.