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

91–100 of 246 posts

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

#91

Post by neverminder »

corysama wrote: post #78
neverminder wrote: post #70

Earlier quoted context omitted.

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 try to understand the code and keep it in my memory so that I could predict the behaviour without the debugger. That's the theme I hear when prodding people who (sometimes loudly) say they don't use debuggers. They work on codebases that are either small, solo projects, or change very slowly. That way they can keep an accurate simulation of the entire program in their heads. Meanwhile, I've always worked on codeb…

Not necessarily. For instance, my colleagues work with a fairly large codebase in java which runs on top of a framework written in scala. When they tried to hook up a debugger it drilled the whole stack top to the bottom, naturally and showed them whole lot of scala code. Problem is, these guys don't now scala, only java.

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

#93

Post by wiresurfer »

The most critical step is to get the lib in your workflow , preferably with (build-introspect-debug) capabilities. This increases the upfront time to start, but leads to much quicker "code understanding in my opinion.

TL;DR; Start with the minimum exposed surface area of the project (API), dig through these functions first. Definitely know the initialization sequences the library needs.

This is my approach concerning JS projects or for dealing with other peoples code in general.

First, I make a mental model of what I want to do. !important. Then I write the smallest wrapper needed to start fledging out points where "separation-of-concern" happens.

At this point I should have an idea of what the other persons libraries expose as API. I also should have an idea of what can be done with a unmodified library, and what would need patching.

Then comes monkey-patching the lib at individual function levels with a healthy dose of TODO markers and NotImplemented Method signatures.

By this point I should have a good picture of what goes on in the library apart from what gets exposed and would probably have forked a branch by now.

This strategy has been useful not just for JS projects but bigger codebases of java/scala libraries like Lucene Core/Solr or Play framework, Django in the python realm and to limited success with Research code releases like Stanford Core NLP.

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

#94

Post by rymndhng »

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!

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

#95

Post by aleem »

Some good pointers and links here, surprisingly they miss both my favourite approaches.

1. If it's on Github, find an issue that seems up your alley and check the commits against it. Or the commit log in general for some interesting commits. I often use this approach to guide other devs to implement a new feature using nothing more than a previous commit or issue as a reference and starting point.

2. Unit tests are a great way to get jump started. It functions as a comprehensive examples reference--having both simple and complex examples and workflows. Not only will it contain API examples but it will also let you use experiment with the library using the unit test code as a sandbox.

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

#96

Post by jeremiep »

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.

The debugger being sequential is a consequence of your code also being sequential at the CPU level.

Understanding the code is often a luxury we don't have, either because we didn't write it in the first place or because there are just too many moving parts each tracking their own state and interacting with everything under the sun.

This is especially true for long-running programs that do much more than just transform inputs into outputs. For example a video game would be complete hell to develop without a solid debugger. Even if you believe you understand the complete code and all its behavior the testers will always find a way to make the game crash after 2 hours of playing leaving the game's state completely broken and without a debugger you'll be scratching your head endlessly trying to replay how that happened.

In these cases the number of different states and behaviors you can get out of the system is incredibly high, easily a few orders of magnitude more than the human brain can handle.

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

#97

Post by rajathagasthya »

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…

Thanks for sharing. For someone in their early career like me, this is very useful.

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

#98

Post by barnacs »

I think a top-down approach is pretty much the only way to do it: Start at a high level of abstraction: packages, modules, namespaces, etc and their relations. Pick one that seems related to some core functionality or central to the change you intend to make and dive deeper: interfaces and data structures within that unit and possibly other related units they depend on. Ideally, up to this point you shouldn't even have to worry about function definitions and algorithms, just declarations, types and relations.

While static typing helps a lot with this kind of exploration and navigation, I don't know of any IDEs or other tooling for any language that would really help you with it. Sure, you can probably generate UMLs or something, but it usually requires some additional tool and the output is pretty static. You can't just zoom in from a package-level view to an interface-level and then keep zooming until you are eventually shown line-by-line implementation of a specific function.

I've been thinking about this lately, and I've come to the conclusion that the way we think and reason about code is pretty far from the way our tools present it to us. I tend to think in terms of various levels abstractions and relations between units, yet the tools just show me walls of text in some file system structure (that may or may not mirror the abstractions) and hardly any relationships.

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

#99

Post by JustSomeNobody »

1. I make sure I can build and run it. I don't move past this step until I can. Period.

After that, if I don't have a particular bug I'm looking to fix or feature to add, I just go spelunking. I pick out some interesting feature and study it. I use pencil and paper to make copious notes. If there's a UI, I may start tracing through what happens when I click on things. I do this, again with pencil and paper first. This helps me use my mind to reason about what the code is doing instead of relying on the computer to tell me. If I'm working on a bug, I'll first try and recreate the bug. Again, taking copious notes in pencil and paper documenting what I've tried. Once I've found how to recreate it, I clean up my notes into legible recreate steps and make sure I can recreate it using those steps. These steps are later included in the bug tracker. Next I start tracing through the code taking copious notes, etc, etc. yada yada. You get the picture.

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

#100

Post by jeremiep »

gbersac wrote: post #44
collyw wrote: post #34

Earlier quoted context omitted.

I am surprised how few younger programmers use a debugger these days.

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

I tend to do that mostly for concurrent programs, as I want to see what happens without blocking the entire system like a debugger would.

For medium/large programs I'll often prefer a debugger because I can easily and quickly try to diagnose the problem without having to wait for a new build to complete with the added traces.

Post reply on HN