Live data from Hacker News

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

news.ycombinator.com

51–60 of 246 posts

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

#51
post #34

Earlier quoted context omitted.

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

I'm not a younger programmer and I don't use a debugger. Tried it several times and found it counterproductive.

Like with most useful tools, you have to use it more than "several times" to gain fluency.

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

#52
post #34

Earlier quoted context omitted.

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

I'm not a younger programmer and I don't use a debugger. Tried it several times and found it counterproductive.

How is it counterproductive exactly? The setup of the debugger itself? Or trying to figure out how it works?

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

#53
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…

This is my approach too. I like to understand the entire flow, from the beginning to the end. To me this is the best way to get familiar because once you dive from different entry points you start noticing the patterns and similar paths in the code to the point where you don't need to dive to those areas again, as you quickly assimilate them by simply going over multiple times.

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

#54

I wrote some simple bash scripts around git which allow me to very quickly identify the most frequently-edited files, the most recently-edited files, the largest files, etc. https://github.com/gilesbowkett/rewind it's for assessing a project on day one, when you join, especially for "rescue mission" consulting. it's most useful for large projects. the idea is, you need to know as much as possible right away. so you r…

Very cool! Thanks for sharing your scripts.

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

#55
post #44
post #34

Earlier quoted context omitted.

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

I just use printf and other stuff to dump critical variable. I also use unit test a lot.

Ah yes, the good ol' printf-debug-polluting-codebase method. What's fun after that, is when programmers all start competing to have their printf's be more visible in the sea of prints ... I find this method primitive at best. How do you manage it?

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

#56
Whatever your IDE/editor of choice is, I think these having these three functions are critical to learning a new codebase, or even developing for that matter: 1. Go to definition 2. Find all references 3. Navigate back

This allows you to go down any code rabbit hole, figure stuff out, then get back to where you were. If you can't do those things it will take much longer to understand how things are interconnected.

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

#57
Whatever your IDE/editor of choice is, I think these having these three functions are critical to learning a new codebase, or even developing for that matter: 1. Go to definition 2. Find all references 3. Navigate back

This allows you to go down any code rabbit hole, figure stuff out, then get back to where you were. If you can't do those things it will take much longer to understand how things are interconnected.

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

#60
I studied a lot of people doing this as part of my PhD. The thing is that there are not many answers that work well in a lot of situations. Given that though, my suggestions is to iterate on developing three views of the code:

1. The Mile High View: A layered architectural diagram can be really helpful to know how the main concepts in a project are related to one another. 2. The Core: Try to figure out how the code works with regards to these main concepts. Box and arrow diagrams on paper work really well. 3. Key Use Cases: I would suggest tracing atleast one key use case for your app.

Post reply on HN