A very simple method that helps me is to make sure I tackle a new code base on a large monitor, vertically oriented, with small font size. Add to that a pane that shows the file/class structure. Seeing more at once helps ground me in the types of interactions in the code and the code landscape.
Ask HN: How do you familiarize yourself with a new codebase?
101–110 of 246 posts
Re: Ask HN: How do you familiarize yourself with a new codebase?
#102A very simple method that helps me is to make sure I tackle a new code base on a large monitor, vertically oriented, with small font size. Add to that a pane that shows the file/class structure. Seeing more at once helps ground me in the types of interactions in the code and the code landscape.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#103Earlier 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 find this method primitive at best. How do you manage it?
Don’t be primitive about it. :-)
The serious answer is: use a good logging framework. In particular, I’d suggest something that can log at selective levels of information for different parts of your system.
If your project’s culture is to instrument your code like this routinely, it can be a very useful asset, and it’s no more disruptive in practice than say adding comments or writing tests. In each case, with experience you get better at judging where to focus your efforts and how much detail is worth including by default, and if that turns out not to be enough you can always add more while you’re working in that area.
With modern tools for recording and analysing logs, there is relatively little useful information that you can easily find using a debugger but can’t easily find from good log output. On the other hand, logging has some big advantages: you can capture how your system changes over time, you can record and review concurrent behaviour cleanly, you can capture information from different parts of distributed systems that might be written in different programming languages or running on different devices.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#104I work on AOSP, which is a fairly larger code base. During the early years, the documentation on the internals of Android was close to non-existent. Plenty of tutorials in Mandarin/Cantonese, but not many in English.
A good way to get hang of the code base was to read it (usually using a tool like sourcegraph [0], pfff [1], open-grok [2], doxygen [3], javadocs [4]). Although a lot of people have argued that code is to be not treated like literature [5], but in this case, there was no choice.
The second step was to see if assumptions about the what the code does is correct. This is usually achieved by adding log statements, writing sample apps, and debugging in general.
Repeat the steps above, over and over again.
Checklist:
1. No matter what you do, you absolutely need to document everything you understand / misunderstand about the code base.
2. Never underestimate value of having a different pair of eyes look at code you have hard time reasoning about.
3. Be in constant search for resources (like books, blogs) available on the code / topic of your interest. You'd learn amazing amount by reading through other people's analysis. Stackoverflow is a great start. Heck, you can even ask well thought-out questions on Quora/Stackoverflow.
4. Hang out on related IRC channels / community mailing lists. For things written in esoteric languages such as OCaml, I found these to be pretty helpful.
5. You could blog about it, share the information you know over email lists, setup wikis; and people who know better would correct you. Its a win-win.
Good luck.
[1] https://github.com/facebook/pfff
[2] https://opengrok.github.io/OpenGrok/
[3] http://www.stack.nl/~dimitri/doxygen/
[4] http://www.oracle.com/technetwork/articles/java/index-jsp-13...
Re: Ask HN: How do you familiarize yourself with a new codebase?
#105Another thing that is helpful, especially if you don't even have knowledge of the problem domain of the codebase: Write a glossary.
As you read the code and encounter terms/words you don't know, write them down. Try to explain what they mean and how they relate to other terms. Make it a hyperlinked document (markdown #links plus headings on github works pretty well), that way you can constantly refresh your memory of previous items while writing
Items in the glossary can range from class names / function names to datatype names to common prefixes to parts of the file names (what is `core`? what belongs there?)
Bonus: parts of the end result can be contributed back to the project as documentation.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#106I try to compose a formal model and algebra of the codebase - quite informally, mind you. Takes a bit of pen and paper and a few caffeinated drinks usually.
People really do learn quite differently and everyone needs to find their mode of learning - there is no one single true way. This is one of the most important skills in software development, IMO. Once you learn how you learn you can apply it to most new contexts.
I write stuff down because for me that-the process of writing seems to be the most effective way to learn.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#107One idea is to use Linux's `perf` to sample stack traces, as the program is running, over a minute or so and see where the code flows.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#108IMO, the one tool you can't do without is grep.
My typical strategy is to get the project running, then just get to work. Start fixing bugs, and adding requested features. Use the code around you as a guide on what is right and wrong within that company, and forge forward. When you are unsure of something turn to grep, find some examples, and keep going.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#109Earlier 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?
In my case, aggressively reject any printf statements in code review. Get that shit out of my repo.
Re: Ask HN: How do you familiarize yourself with a new codebase?
#110Back when I did Java, using static analysis tools like findbugs, then going and fixing all the issues found was a good way to get coverage of the codebase... I'm sure for JS there must be similar analysis tools.