Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How do you familiarize yourself with a new codebase?

news.ycombinator.com

Post reply on HN
Print view View original

191–200 of 246 posts

Re: Ask HN: How do you familiarize yourself with a new codebase?

#191

Post by fourier »

PirateDave wrote: post #180
fourier wrote: post #145

I'm working a lot with a huge legacy codebases in C/C++. Here are some advices: 1. Be sure what you can compile and run the program 2. Have good tools to navigate around the code (I use git grep mostly) 3. Most of the app contain some user or other service interaction - try to get some easy bit (like request for capabilities or some simple operation) and follow this until the end. You don't need a debugger for it - g…

4. Sometimes writing UML diagrams works I found myself doing this more often and find it very useful. I've been using Freemind and it seems to do the trick. http://freemind.sourceforge.net/wiki/index.php/Main_Page

Yes this could work for personal things. But it is often you need to represent your understanding of the current state of affairs and propose your ideas, so the UML is a good tool to do it - everybody understand it or could learn in like 0.5 hour.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#192

Post by coolsunglasses »

If it's in Haskell, I start cleaning up and refactoring datatypes.

Like changing some function like:

   Text -> Text -> IO ()
into:

   ServerHost -> Path -> IO ()
Changing the types will naturally lead you through the codebase and help you learn how everything fits together via the type errors.

In any language I'll try to read the project like the Tractatus.

In stuff that isn't Haskell? Break stuff and run the tests.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#193

Post by slightlycuban »

scott_s wrote: post #23

A post from last year, "Strategies to quickly become productive in an unfamiliar codebase": https://news.ycombinator.com/item?id=8263402 My comment from that thread: I do the deep-dive. I start with a relatively high level interface point, such as an important function in a public API. Such functions and methods tend to accomplish easily understandable things. And by "important" I mean something that is fundamental t…

Interesting. I take a similar approach, but then I add testing (which usually coincides with fixing some bug).

Find an entry point to the system, then make it compile, then make the test run, then just keep on nudging the code until I'm satisfied I've covered what I'm interested in.

If I stay true to my mantra "only add test code when it is absolutely necessary" (is this argument needed? pass null and find out), I find an accurate (albeit not pretty) description the flow through that procedure.

Then you commit your test and save your discovery for posterity.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#194

Post by jpgvm »

I usually work on more traditional command line applications and daemons so my approach might be a little different to a web developer.

I always start by gauging how much source code there is and how it's structured. The *nix utility "tree" and the source code line counter "cloc" are usually the first 2 things I run on a codebase. This tells me what languages the applications uses, how much of each, how well commented it is and where those files are.

The next thing I usually do is find the entry point of the program. In my case this is usually an executable that calls into the core of the library and sets up the initial application state and starts the core loop and routine that does the guts of the work.

Once I have found said core routine I try to get a grasp for how the state machine of the program looks like. If it's a complicated program this step takes quite a while but is very important for gaining an intuitive understanding of how to either add new features or fix bugs. I like to use my pen and paper to help me explore this part as I often have to back track over source files and re-evaluate what portions mean.

Once I have what I think is the state machine worked out I like to understand how the program takes input or is configured. In the case of a daemon that often means understanding how configuration files are loaded and how the configuration is represented in memory. Important to cover here is how default values are handled etc. I actually prioritise this over exploring the core loops ancillary functions (the bits that do the "real" work) as I find it hard to progress to that stage without understanding how the initial state is setup.

Which brings us to said "real" work. Hanging off of the core loop will be all the functions/modules are called to do the various parts of the programs function. By this time you should already know what these do even if you don't know how they work. Because you already have a good high level understanding at this point you can pick and choose which modules you need to cover and when to cover them.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#195

Post by archagon »

collyw wrote: post #34
monk_e_boy wrote: post #12

Debugger! Surprised no one has mentioned it yet. I work in js and php, both of which I use the debugger a lot . Set a breakpoint, burn through the code. Chrome has some really nice features - you can tell it to skip over files (like jQuery) you can open the console and poke around, set variables to see what happens. Stepping though the code line by line for a few hours will soon show you the basics.

I am surprised how few younger programmers use a debugger these days.

Maybe this is just my lack of experience speaking, but I find debuggers incredibly difficult to use when dealing with interactive software (which is most software I work on). Hitting a breakpoint freezes my interaction unless I configure it to print something, and configuring it to break conditionally requires knowing some obscure incantations that I can never remember off the top of my head (and that in turn require their own debugging). So it boils down to: should I spend 5 minutes figuring out how to set this conditional, print-only breakpoint? Or should I just put in a printf? The solution, at least to me, is obvious.

(With that said, when I have a nasty bug that requires squishing around in the guts of my program, breakpoints are invaluable. But it's a pretty huge hammer that only comes out on occasion.)

EDIT: I wonder how useful an editor that allows inline debugging code would be? Instead of setting breakpoints in your IDE and then configuring them in an individual window, you'd enter a "debugging editor" mode that would allow you to add debugger-only code for things like conditional breakpoints and printf statements right alongside your normal code. The original source files would not be edited, but while in this mode, it would appear as if they were. (Maybe the debugging code would show up in red.) That way, you could easily access all your local state and implement complicated queries without ever leaving the context of your code. In other words, it would be just like printf debugging, but once you no longer need to debug you'd just collapse those statements out by leaving the debugging editor mode and your original code would be unchanged. Perhaps this debugging code would not compile along with the rest of the code but would instead use the debugging hooks that normal breakpoints use, unless the conditions are particularly complex or something. Just a thought.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#196

Post by girvo »

noir_lord wrote: post #147
barrkel wrote: post #131

Earlier quoted context omitted.

printf = breakpoint expression evaluation (but without the flexibility) You're using a primitive debugger, you just don't know it.

It does have the advantage of both immediacy and continuation. You can dump statements through a function and see it's progression when run without having to interact with it. Throw in something like FirePHP (which allows dumping pretty much anything out as a viewable/collapsible trace, other languages have similiar) and the use case for a lot of using a full blown debugger is removed (it's still incredibly powerful…

Codebug + Xdebug, setting a breakpoint and getting a full REPL at that execution point is far more useful to me when I'm in PHP land :)

Re: Ask HN: How do you familiarize yourself with a new codebase?

#197

Post by girvo »

shogun21 wrote: post #17
monk_e_boy wrote: post #12

Debugger! Surprised no one has mentioned it yet. I work in js and php, both of which I use the debugger a lot . Set a breakpoint, burn through the code. Chrome has some really nice features - you can tell it to skip over files (like jQuery) you can open the console and poke around, set variables to see what happens. Stepping though the code line by line for a few hours will soon show you the basics.

What debugger do you use for PHP? I've yet to find one I really like.

Codebug. Phenomenal Xdebug client.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#198

Post by dave_ops »

I take it out for dinner and drinks. Spend some time getting know about it and where it comes from and what it does for a living. Then after we're a few cocktails in we get all philosophical. Really start asking the hard questions like, "Why do I even exist? Is any of this real or is it all some weird virtual world?"

We become fast friends and feel like we really understand each other.

But days pass, and each encounter feels less magical. It's almost like we having nothing in common. Like we're from two completely different worlds. One where its stuck in the past and one where I'm ambitious and excited about the future.

After awhile we don't really speak to each other anymore, and after some pretty ugly fights at work that get too personal... I rewrite it.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#199

Post by gregulator »

I've had to ramp up quickly on a number of projects so far during my career, and I can tell you there's no substitute for simply reading the heck out of the code. Yes it takes discipline to go through code line-by-line, and at times may seem pointless or like its "not sticking". But persistence here pays dividends.

The first read-through is not about comprehending everything. It's about exposing your mind to the codebase and getting it to start sinking into your subconscious. It's kinda like learning a new piece on the piano.

Re: Ask HN: How do you familiarize yourself with a new codebase?

#200

Post by xarien »

I'd speak to the last person who worked on it face to face with a whiteboard and a marker handy. Get a brain dump ASAP. Even if the person no longer works there, you can take some time to contact them for a lunch. Most people would not say no to this type of request (especially if you're buying). Just make sure you have questions ready so you don't waste their time.
Post reply on HN