* Trying to completely learn how an application works
* Trying to figure out a specific issue or bit of behavior.
For case #1, you generally look for an entry point and spread out from there. For case #2, you're mostly concerned with a specific chunk of code, probably related to an error message you're interested in, so you do some quick searching or digging to jump straight down to the relevant spot.
* Run a `tree` and a `tree -d` to figure out the global structure of the project and try to understand how it's organized. Read most file names and try to look inside some files
* If one or more authors of the code are available to guide you, ask them (reading through the project structure first really helps to understand what they'll tell you about)
* If there are tests, read them, they're a very useful resource to understand what the code actually does
* If there are docs (particularly diagrams, but anything can help), read them
* If there is an entry point to the program, try to follow it and draw sequence diagrams (-ish, no need to be thorough if it's for you, but keep in mind it can be used by someone else (maybe even future-you) later so try to keep it clean and digitalized). For this you can also use a debugger and place some breakpoints wherever you want
* Read the code, modify it to see what happens, and add comments to what you manage to understand
Second step, I find the main() function so I can start following references.
First step, I find the project's issue tracker to get a sense of what state it's in. Is it under active development? Is it half-finished, maintained? Are there giant problems unaddressed?
4 comments
[ 1.4 ms ] story [ 18.3 ms ] threadAsk questions about configuration and architecture.
Learn how to reproduce peer successes.
The actual purpose of the code base is important for a good answer: elaborate "code base".
* Trying to completely learn how an application works * Trying to figure out a specific issue or bit of behavior.
For case #1, you generally look for an entry point and spread out from there. For case #2, you're mostly concerned with a specific chunk of code, probably related to an error message you're interested in, so you do some quick searching or digging to jump straight down to the relevant spot.
This article is a great example of that sort of behavior and thought process: http://www.lihaoyi.com/post/DivingIntoOtherPeoplesCode.html
* Run a `tree` and a `tree -d` to figure out the global structure of the project and try to understand how it's organized. Read most file names and try to look inside some files
* If one or more authors of the code are available to guide you, ask them (reading through the project structure first really helps to understand what they'll tell you about)
* If there are tests, read them, they're a very useful resource to understand what the code actually does
* If there are docs (particularly diagrams, but anything can help), read them
* If there is an entry point to the program, try to follow it and draw sequence diagrams (-ish, no need to be thorough if it's for you, but keep in mind it can be used by someone else (maybe even future-you) later so try to keep it clean and digitalized). For this you can also use a debugger and place some breakpoints wherever you want
* Read the code, modify it to see what happens, and add comments to what you manage to understand
Obviously take notes of everything you learn.
First step, I find the project's issue tracker to get a sense of what state it's in. Is it under active development? Is it half-finished, maintained? Are there giant problems unaddressed?