Ask HN: How you get familiar with a codebase fast?

[mushfiq]

Hello All,

I was just curious, what are the strategy you follow to understand a codebase. May be you have specific way to do it. I would like to know it. And I think it will help others also to improve.

Thanks in advance.

[cjbprime]

I like function tracing -- pick an operation you're interested in, get a line printed with the name of each function that gets entered in order. Here's an example from the kernel:

http://thread.gmane.org/gmane.linux.kernel.mmc/4248/focus=44...

[anoxic]

"Rapid learning" and troubleshooting methods. The process for both of these is nearly identical, although some details differ. There are several books by Steve Litt that go over these and I found helped me troubleshoot problems faster than most of my co-workers, but the same principles helped me to understand a new code base much faster.

Available books by Steve Litt: http://www.troubleshooters.com/bookstore/index.htm

A nice book package, I recommend these to every developer I meet: http://www.troubleshooters.com/bookstore/recession_package_a...

His website isn't pretty, but the content is golden.

[ChintanGhate]

I wrote a program that parses all files in the codebase (I mainly work with Objective-C frameworks and libraries), and forms a graph using all the imported 'header files' in each file. Then when I need to fix a bug or implement an API, I input the base-file name and the program spits-out all the header dependancies of the base-file in a tree format. This way I am able to limit the area of the codebase I need to focus on to solve the issue at hand. I keep on focusing on these small areas of codebase one after another and get familiarized with it pretty quickly.

[JoeAltmaier]

I read it, skim every module if I can. E.g. I worked on a 500-file project (Broadcom had managed to take a 9-module driver and refactor it into 500 files!), reduced it to some classes and simplified headers. When I was done (took weeks) it was like 1% the size of the original pile. And I think I had not left anything important behind.

[antocv]

Read books on various design patterns and architectures, until you start seeing patterns whenever you look at code.

Just try to see which context the stuff is supposed to execute under, what problems it solves - from there the code is easy.

[varl]

I pick an issue from the bug tracker and start working on it.

[loumf]

This is the standard recommended book:

http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...

I write new tests in any area I'm going to be working in.

[RollAHardSix]

Start fixing defects. Nothing major, but it will certainly help you understand how and why things are ticking the way they are.

[fsk]

grep

[stevekemp]

Do take a look at "ack-grep" if you've never done so before. Although it isn't significantly different it is so much nicer to see things be excluded from .git/ and similar.