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

211–220 of 246 posts

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

#211

Post by azeirah »

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…

I made a crappy visualization of the commits of our University project, http://codepen.io/Azeirah/pen/bdawBm

It was a 3D pong game, along with the game engine. Pretty neat to see this visualized.

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

#212

Post by h8liu »

baby wrote: post #210
h8liu wrote: post #126

Earlier quoted context omitted.

For golang std lib, since packages have no circular deps, it can be automatically drawn out like this: http://lonnie.io/gostd/dagvis/ If you write your project that even has no circular deps among files and all files are small (like me in https://github.com/h8liu/e8vm ), you can draw the similar graph but at a much finer granularity, like this: http://8k.lonnie.io/

wow! What did you use to make these? It looks awesome!

Thanks.

Here are my hand-made tools to generate those stuff: https://github.com/h8liu/e8tools

Javascript version (I actually wrote this first for go std lib): https://github.com/h8liu/dagvis

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

#213

Post by tracker1 »

Try to fix/change/adjust something in the front-end and look back from there... Although this can be frustrating depending on the codebase, but your best bet in learning something new is to try to do something... even something small. If you want to go the extra mile, add comments to stuff that doesn't make sense as you go, and tag things for refactoring with Todo's and corresponding tickets.

Going a step farther still would be to add to the user documentation as you go...

Do something small, and iterative, and go out from there... for that matter, just getting a proper build environment is hard enough for some projects... automate getting the environment setup if it's complex. I've seen applications with 60+ step processes for getting all the corresponding pieces setup.

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

#214

Post by mavidser »

jdavis703 wrote: post #31
mavidser wrote: post #14

Well, I'm not very good at this either but here's what I do. I usually work on modular projects where there are hundreds of files in the project. I usually skip directly to locating the file where I've to make amends (using a lot of grep. grep for function and object definitions, grep for usage patterns, grep for checking how to implement something). Thus, I learn about the codebase as I go along. Sure, this is not t…

If this is your modus operandi your life will be much improved with Ack. It's specifically designed for searching codebases.

Thanks. I'm looking at it right now, and it looks really cool.

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

#215

Post by joe_the_user »

kabdib wrote: post #28

I just crack open the source base with Emacs, and start writing stuff down. I use a large format (8x11 inch) notebook and start going through the abstractions file by file, filling up pages with summaries of things. I'll often copy out the major classes with a summary of their methods, and arrows to reflect class relationships. If there's a database involved, understanding what's being stored is usually pretty crucia…

Great points Also,

A list of the kinds of broad abstractions to look for might be useful;

* Each module and it's purpose

* Every global resource (whether global variables, message names, anything that the entire system has to deal with).

* The "style" that each coder used. Even "terrible" programmers tend to have a consistent approach and understanding that approach can make code much less opaque.

I also like to page though documents more quickly than my conscious mind can follow so as to get an unconscious feel for a code base. That might be just me.

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

#216

Post by john2x »

rymndhng wrote: post #94
kabdib wrote: post #28

I just crack open the source base with Emacs, and start writing stuff down. I use a large format (8x11 inch) notebook and start going through the abstractions file by file, filling up pages with summaries of things. I'll often copy out the major classes with a summary of their methods, and arrows to reflect class relationships. If there's a database involved, understanding what's being stored is usually pretty crucia…

Totally agree with the point of pen/paper. Something that compliments that approach is in-code annotation. Recently, I've recently been trying out https://github.com/bastibe/annotate.el which is pretty sweet. Check it out!

Off topic, but anyone know what font and theme (it looks like the default theme but I'm not sure) are used in the project's screenshots?

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

#217

Post by zodvik »

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…

Very simple & quite effective. Thanks for sharing.

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

#218

Post by mercurial »

Mithaldu wrote: post #179
lukaslalinsky wrote: post #175

Earlier quoted context omitted.

Ah, so long enough for the advice to be based on real experience. I was really surprised to see it, because it's exactly the way I was learning C. I switched to Linux around the same time, so I'd take some abandoned DOS program that had source code available and port it to Linux. During the process, I'd read the entire source code, make sure I understood it and reformatted everything. A few years later, the original…

Three things to keep in mind here: 1. Perl is MUCH more concise than C, since we have institutionalized code sharing (see CPAN), whereas most C devs i know (and maybe i don't know too good ones) seem to at most reuse code others wrote by way of ctrl+c/ctrl+v. 2. Perl's reformatting tools are automatic. I just have a little config file that says how long my lines are supposed to be and where i'd like the spaces on my…

The big problem (apart from the fact that ill-formatted codebases have often much more serious problems...) is that reformatting is an excellent way of messing up your VCS' diff ability, which is extremely precious in trying to understand why things have been done the way they have.
Post reply on HN