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

14 points by mushfiq 11 years ago | 10 comments

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 11 years ago |

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 11 years ago |

"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 11 years ago |

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 11 years ago |

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 11 years ago |

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 11 years ago |

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

loumf 11 years ago |

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 11 years ago |

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

fsk 11 years ago |

grep

stevekemp 11 years ago | |

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.