Live data from Hacker News

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

news.ycombinator.com

181–190 of 246 posts

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

#181

Read it until I can identify which fad of the moment the author was following.

This is a particularly insightful (if snarky) comment.

The project I just had to refactor had a DSL that was completely unnecessary and had a ton of business logic tangled up within the domain language itself. I ended up being able to remove the DSL and parser completely in lieu of using simple config files and extracting the business logic into middleware.

The DSL was probably originally created due to some Slideshare presentation that had just hit the top of HackerNews 3 years ago. The original devs molded the problem to fit the ability to use a DSL and cool parsing library rather than figure out what the most suitable design for the problem was.

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

#183
I like to try two impractical tasks (impractical in the sense that they might not be possible, which is fine).

1. Access some data in the highest level component from one of the lowest level components

2. Access some data in one of the lowest level components from one of the highest level components

In a lot of cases, good architecture will prevent one or both of these from being possible, but identifying how data flows through the app seems to be a good way to understand the general architecture, limitations and strengths of most apps. These two tasks give concrete starting points for tracing the data flow.

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

#185

Earlier quoted context omitted.

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.

Isn't ag a better option these days?

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

#186
The first thing I do is try to get a handle on the libraries it pulls in (maybe spend a day just going through the high-level readme material for each one). That will usually tell me where to start looking for the entry points where I might want to start modifying things. After that, I give myself a series of small functionality changes to implement, kind of like capturing a bunch of little flags. After doing that for a bit I usually have a decent idea of how things work, and it's easier to go forward, at which point I can dig into the relevant parts of the codebase with more confidence.

The first few mods are inevitably disgusting hacks, so don't pick anything you want to keep for your first couple of goals. It is pretty easy to go back and do them right once you've got your head around the rest of the project if you do end up wanting to keep them though.

I've used this method on some decently large C++ and javascript projects (around 100k-200k lines) and it works pretty well for me. I don't learn very well by just reading the code, but doing the little mods seems to make it stick.

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

#187
I don't do code reading or comprehension study. Reading code is boring. I typically create a list of small tasks that I want to achieve with the project. If the task is big, I break it down into smaller tasks. Then I rank the tasks from easy to hard. This way, I can start learning about the codebase and achieve my tasks.

In your case, frozen columns seems to be a hard feature. So I would start with ajax data source. I'd start with a simple SlickGrid example and get it to run. Then go find how SlickGrid sets up data source. Expand that piece of code to add ajax data source. Once I finished ajax data source, I'd dig into frozen columns.

If you are working on a new codebase and worry about bugs, you just give yourself more stress. Bugs (that are not yours) are expected. If they aren't blocking your task, ignore them. Most likely, they aren't relevant to what you are trying to do.

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

#189
post #63
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?

You remove the printfs when you have fixed the problem.

It's so tempting to do this. Don't. Problems may occur again in the same area. Leave your logging statements around; configure your logging setup to skip them when you don't want them.

You're saying to delete commented-out code once the new code works. Put your code in version control instead. Logging is to once-off printfs as version control is to commented-out code.

Post reply on HN