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

141–150 of 246 posts

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

#141

Post by neves »

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.

Debuggers and profilers are essential tools, but I was surprised when I read the book "Coders at Work: Reflections on the Craft of Programming" that a lot of the greatest programmers debugged just with a printf.

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

#142

Post by tessierashpool »

baby wrote: post #135
tessierashpool wrote: post #32

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…

Is it normal that it takes a while > 2minutes to run your program on some big java repo? edit: took like 4 minutes, worked well!

quoting from the readme:

Caveat: Running this code against extremely large projects with very long histories (e.g. Rails) might be very slow.

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

#143

Post by lberger »

ninkendo wrote: post #109
kelvin0 wrote: post #55

Earlier quoted context omitted.

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?

In my case, aggressively reject any printf statements in code review. Get that shit out of my repo.

Without trace statements, how do you diagnose issues that don't occur locally and only appear in the production environment.

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

#144

Post by agentgt »

Mithaldu wrote: post #6

This may or may not apply to you, since i work with Perl. Typically i'm in a situation where i'm supposed to improve on code written by developers with less time under their belt. As such my first steps are: 1. tidy/beautify all the code in accordance with a common standard 2. read though all of it, while making the code more clear (split up if/elsif/else christmas trees, make functions smaller, replace for loops wit…

A while back I worked with team that had just brought on some new developers. Some of the developers were eager and would learn with out human intervention. Others would require and ask for some mentoring.

Neither way of learning is right or wrong and I appreciated both groups but one thing I did remember was one guy that did exactly what you did and it was highly irritating as a project lead to see relatively random files (given whatever sprint we were on) that were considered stable to show up in the source control change list with out some consideration of discussion. I would have to waste time and look what change he made to see if it was ok.

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

#145

Post by fourier »

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 - grep/git grep is enough, these simple tools will force you to understand codebase deeply.

4. Sometimes writing UML diagrams works -

- Draw the diagrams (class diagrams, sequence diagrams) of the current state of things

- Draw the diagrams with a proposal of how you would like to change

5. If it is possible, use a debugger, start with the main() function.

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

#146

Post by blakeyrat »

neverminder wrote: post #70
kelvin0 wrote: post #52

Earlier quoted context omitted.

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

It's a complicated explanation I suppose, but I would say that among other things, I've seen my colleagues abusing debugging and since debugger is a "single threaded" and sequential approach if you will, they were losing the big picture. I try to understand the code and keep it in my memory so that I could predict the behaviour without the debugger. On a better day this would be a better explanation.

I'm not sure how you "abuse" debugging-- can you elaborate on that?

The debugger runs in as many threads as the app itself. If you're debugging C#, and your program is in 37 threads, you can debug all of them simultaneously or debug one and ignore the others.

Understanding the code and keeping it in memory sounds like a great practice, but it also seems entirely orthogonal to using a debugger.

I have the exact opposite attitude: I live in the debugger. Most of my resistance to trying "new hot" languages is their universally terrible debuggers. (Usually they either don't exist at all, or only exist in CLI form.) IMO, if you don't have a working, stable, graphical debugger, your programming language has no business being 1.x.

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

#147

Post by noir_lord »

barrkel wrote: post #131
gbersac wrote: post #44

Earlier quoted context omitted.

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

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 when needed).

So I use both.

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

#148

Post by Mithaldu »

lukaslalinsky wrote: post #47
Mithaldu wrote: post #6

This may or may not apply to you, since i work with Perl. Typically i'm in a situation where i'm supposed to improve on code written by developers with less time under their belt. As such my first steps are: 1. tidy/beautify all the code in accordance with a common standard 2. read though all of it, while making the code more clear (split up if/elsif/else christmas trees, make functions smaller, replace for loops wit…

Please don't take this as a criticism, but how long have you been programming? I'm asking because I used to have an opinion like this when I was just starting, but after a few years I realized that changing all of the code as the first thing is one of the worst things to do.

For pay since 2005. Do keep in mind that the code i am working with usually has some sort of test suite available, and that over time i have become very good at transforming code between different forms of expression without changing the effects it causes. (Excluding memory use and performance, which is not something one usually has to consider much in Perl.)

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

#149

Post by noir_lord »

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.

Xdebug and with phpstorm 9 you have inline display of the values held in that variable which you can expand with a click.

That is incredibly powerful (PyCharm has it as well).

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

#150

Post by Mithaldu »

agentgt wrote: post #144
Mithaldu wrote: post #6

This may or may not apply to you, since i work with Perl. Typically i'm in a situation where i'm supposed to improve on code written by developers with less time under their belt. As such my first steps are: 1. tidy/beautify all the code in accordance with a common standard 2. read though all of it, while making the code more clear (split up if/elsif/else christmas trees, make functions smaller, replace for loops wit…

A while back I worked with team that had just brought on some new developers. Some of the developers were eager and would learn with out human intervention. Others would require and ask for some mentoring. Neither way of learning is right or wrong and I appreciated both groups but one thing I did remember was one guy that did exactly what you did and it was highly irritating as a project lead to see relatively random…

Understandable. I'm also operating quite differently. Typically i am called into teams who are floundering already. So what i do is create one big commit with the goal of making the code easier to work with and to learn about the code base. Never do i just change random files, and never do i do it without the team lead having agreed and some sort of concensus from the rest of the team.
Post reply on HN