I try to work backwards from the public api to get a sense of the operations that are supported by the system. A trick I picked up from a thoughtbot training video a couple years ago for Rails applications is to look at the routes file. If you work with webapps, the routes generally define the things that people can do.
Ask HN: How do you familiarize yourself with a new codebase?
61–70 of 246 posts
Re: Ask HN: How do you familiarize yourself with a new codebase?
#62I 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…
Thanks for sharing. I often get lost in large projects. Blindly jumping around is quite inefficient and frustrating.
How hard do you think it is to write a tool to draw dependencies map for a specific language?
May be there're built-in code analyzing tools in compilers for popular languages that I'm not aware of?
Re: Ask HN: How do you familiarize yourself with a new codebase?
#63Earlier quoted context omitted.
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?
You remove the printfs when you have fixed the problem.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#64Debugger! 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.
http://codebugapp.com is a fantastic front-end for Xdebug. I get a lot of mileage out of this, not least because I only had to set it up once and now it works with whichever editor I'm trying out this week.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#65Earlier quoted context omitted.
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?
I think he meant to add print statements locally. You remove them before committing the code.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#66[deleted]
Re: Ask HN: How do you familiarize yourself with a new codebase?
#67I 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…
Thanks for sharing. I often get lost in large projects. Blindly jumping around is quite inefficient and frustrating. How hard do you think it is to write a tool to draw dependencies map for a specific language? May be there're built-in code analyzing tools in compilers for popular languages that I'm not aware of?
I am reminded of this: http://steve-yegge.blogspot.ca/2007/06/rich-programmer-food....
Re: Ask HN: How do you familiarize yourself with a new codebase?
#68As someone who hates debuggers and is a fan of "learning by doing", I make heavy use of console.log() or similar, and I start putting breakpoints all over the code that print out sentinels ("hey, I'm in this part of the code") and data ("the content of this variable are: XXXX").
Then I run the app and put it through its paces, while watching the output in another console.
If there's some code that doesn't make sense, I use console.log() heavier in that section, to help me fully understand what it does. Once I have that level of understanding, I then write some comments in the code and commit them so that other contributors may benefit in the future.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#69I try to work backwards from the public api to get a sense of the operations that are supported by the system. A trick I picked up from a thoughtbot training video a couple years ago for Rails applications is to look at the routes file. If you work with webapps, the routes generally define the things that people can do.
This routes-trick is my starting point as well on web apps.
The next place I try to understand is the persistence layer - be it the a database scheme or models working against remote APIs. Building a mental model of the the data (around which the app surrounds) serves as a map for the rest of the code tour.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#70Earlier quoted context omitted.
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?
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.