

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

Hello All,<p>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.<p>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...](http://thread.gmane.org/gmane.linux.kernel.mmc/4248/focus=4400)

------
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](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...](http://www.troubleshooters.com/bookstore/recession_package_a.htm)

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...](http://www.amazon.com/Working-Effectively-Legacy-Michael-
Feathers/dp/0131177052)

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.

