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.
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:<p><a href="http://thread.gmane.org/gmane.linux.kernel.mmc/4248/focus=4400" rel="nofollow">http://thread.gmane.org/gmane.linux.kernel.mmc/4248/focus=44...</a>
"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.<p>Available books by Steve Litt:
<a href="http://www.troubleshooters.com/bookstore/index.htm" rel="nofollow">http://www.troubleshooters.com/bookstore/index.htm</a><p>A nice book package, I recommend these to every developer I meet:
<a href="http://www.troubleshooters.com/bookstore/recession_package_a.htm" rel="nofollow">http://www.troubleshooters.com/bookstore/recession_package_a...</a><p>His website isn't pretty, but the content is golden.
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.
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.
Read books on various design patterns and architectures, until you start seeing patterns whenever you look at code.<p>Just try to see which context the stuff is supposed to execute under, what problems it solves - from there the code is easy.
This is the standard recommended book:<p><a href="http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052" rel="nofollow">http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...</a><p>I write new tests in any area I'm going to be working in.