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

151–160 of 246 posts

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

#151

Post by Mithaldu »

jeremiep wrote: post #87
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…

Both points aren't possible to do with large codebases. It will take months merely to tidy the code with the effect of making the rest of the team hate you for committing thousands of files for superficial changes. Its much more productive for everyone to simply adapt to the existing style guidelines. Reading all of the code is only an option for the smallest of codebases. Reading code will only get you so far before…

If i take longer than a week to do it, then other measures are called for, like, as you mention, subsets. However you seem to underestimate just how much functionality can be implemented in how little code with Perl.

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

#152

Post by Mithaldu »

vitorbaptistaa wrote: post #88
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…

Do you follow this process even on code without tests? How do you make sure you're not introducing bugs in the process? Or you don't commit your changes afterwards?

It works even on code without tests, simply due to lots of experience. It helps that i also have a lot of tools available in terms of realtime syntax and sanity checkers. And sometimes if the code is sufficiently insane enough, i'll write tests to make sure.

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

#153

Post by jameshart »

For clientside JavaScript, one useful way in is to run the Chrome profiler on it. That will produce a treeview of the calling hierarchy, and give you an idea of what are the code's 'hotspots' - the functions that are called from everywhere, or the functionality which dispatches everything.

This can be especially useful for event driven code (looks like SlickGrid is jQuery-based, so that definitely applies here); you can start a recording profile, carry out the action you're interested in, then stop recording, and you can then find out exactly which anonymous function is handling that particular click or scroll or drag.

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

#154

Post by crcsmnky »

While this generally works best for larger code bases, I tend to start reading through open bugs/tickets and find things that appear easy. Then I will assign them to myself and do what I can to fix it or at least track it down.

Generally I find it hard to just start reading through packages, source, functions, etc. and find it much easier to try and solve some sort of problem. By tracking and debugging a particular issue through to the end, I find a learn a lot about the codebase.

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

#155

Post by chipsy »

I try to seek out the data structures first. If I need help doing it, I either run a profiler or insert some debug prints to get an idea of what parts of the callstack are "hot" and then progress from that to discovering the data. (Languages that don't require type signatures everywhere often have this problem of hidden structures.)

Once I know what the data is I can look at the code with an eye towards maintenance of data integrity. I might still need some "playtime" to grok the system but the one truism of large software is that data is always getting shoved from one big complicated system to another, and I can usually identify boundaries on those systems to narrow the search space.

(the exception to this is if you have code that leaks global state across the boundaries. Then much swearing will occur.)

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

#156

Post by goblin89 »

Document the codebase, in my experience it helps.

In case of JavaScript you’d probably use something like JSDoc. Describe your units and make the tool automatically create beautiful HTML out of that. You don’t have to document everything at once but be sure to lay the groundwork, automate documentation build process, and in general try to make maintaining the docs effortless (for yourself and for others). Take some existing well-documented JavaScript codebase as an example.

This’d make a great contribution already: SlickGrid’s codebase is somewhat poorly documented, which is a barrier to the involvement of interested developers.

As you write the docs weak spots in existing implementation will come to your attention, helping you figure out what to fix first.

One downside is that writing down and structuring your knowledge in easy for others to grasp way is a challenge in itself, though arguably a useful exercise.

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

#157

Post by shurcooL »

This is not a comprehensive answer, but it's additive.

If you're looking at a large Go codebase with many packages, I find it helpful to visualize their import graph with a little command [0].

Here are results of running it on consul codebase:

    $ goimportgraph github.com/hashicorp/consul/...
http://virtivia.com:27080/cehy9dnqaq92.html

[0] https://github.com/shurcooL/cmd/tree/master/goimportgraph

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

#158

Post by parshimers »

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.

Debugging through the test cases in particular is a good way to decipher/dissect things, at least that I have found. Usually you can find a test case that is only for a specific component that you are interested in, and then the test case should only exercise those pieces, so there is not an overwhelming amount of information all at once.

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

#159

Post by harrumph »

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.

Amen. Once you've had ack, you never go back.

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

#160

Post by jeremiep »

Mithaldu wrote: post #151
jeremiep wrote: post #87

Earlier quoted context omitted.

Both points aren't possible to do with large codebases. It will take months merely to tidy the code with the effect of making the rest of the team hate you for committing thousands of files for superficial changes. Its much more productive for everyone to simply adapt to the existing style guidelines. Reading all of the code is only an option for the smallest of codebases. Reading code will only get you so far before…

If i take longer than a week to do it, then other measures are called for, like, as you mention, subsets. However you seem to underestimate just how much functionality can be implemented in how little code with Perl.

Oh I wasn't talking about Perl specifically but about languages in general. I agree that Perl projects tend to stay small enough to be quickly understood and refactored. In fact I don't remember seeing a Perl script more than a few thousands line long.

However, don't underestimate how hard it can be to understand your own Perl code when you've been away from it for 6 months :)

Post reply on HN