3 ms·

Ask HN: How do you effectively read a new codebase?

techstrategist 7y ago
[sorry for the dupe - got a 500 error and didn’t check /new]
bryanrasmussen 7y ago
That really depends on my level of expertise with the subject matter and the language and probably also what kind of project it is and what I am expected to do, assuming I am pretty proficient then this what I would probably do: Read most current tickets to do, probably some of the backlog to get an overview of what people have problems with. Then I probably start reading what is the main entry point and go through everything just looking for code that is badly written, optimizable, or can otherwise be improved. Finding bad code I write notes to myself on what needs to be improved. I make a ticket to fix things. I go fix things, now I have sort of a high level overview of how the different parts of codebase work together. Maybe I have found architectural things to be fixed (this is of course assuming I am better with language/solution space than team I am coming on to but I often am when hired as a consultant) - for example current project I am on had mixed routing and display of components which in this case was bad architecturally (IMHO it's always a problem but in this case it definitely was one) so I fixed that which further made the structure of whole project clear. If stuff I don't understand I ask whoever is leader, don't just change things that you don't understand to be something you understand, there might be reasons why things are the way they are. Now I probably have had a full week on project and done several improvements. Also going through things I might find stuff that relates to the tickets I saw, if I can see that something relates to a ticket I read take that ticket and fix it as part of other stuff doing. All this helps develop overview of how project hangs together and what problems are.
carlmungz 7y ago
Whilst not directly related to this, I have spoken (https://www.smashingmagazine.com/2019/07/javascript-knowledge-reading-source-code/ https://www.smashingmagazine.com/2019/07/javascript-knowledg...) and written (https://www.smashingmagazine.com/2019/07/javascript-knowledge-reading-source-code/ https://www.smashingmagazine.com/2019/07/javascript-knowledg...) about reading source code. If possible (either via docs or guidance from other developers), I find a major API and then follow it to its end point. You will usually come across other major pieces of the codebase this way and you can make a note of them if you wish to do further digging.
ak39 7y ago
I document it. I first read or find out as much about what the code is supposed to accomplish. After this, I jot down the primary aspects of the program I would expect to see - decompose main functions. Every ancillary aspect of the code I meet I put under headings that I have written down. I write down aspects I expected but didn't find. Beyond this, you get a panga blade! Good luck
pizza 7y ago
I recently started working on a quite large C++ codebase and I'm quite a bit more lost at the moment than I would be had I written all the code. I have a strong suspicion that if I just used the right tooling (eg maybe a GUI that displayed some of the flow of the program's state, or something that made it easy to inspect the running program?) it might be a bit easier. Any tips about y'all's favorite C/C++ tools for learning a new codebase?

[sorry for the dupe - got a 500 error and didn’t check /new]

That really depends on my level of expertise with the subject matter and the language and probably also what kind of project it is and what I am expected to do, assuming I am pretty proficient then this what I would probably do: Read most current tickets to do, probably some of the backlog to get an overview of what people have problems with. Then I probably start reading what is the main entry point and go through everything just looking for code that is badly written, optimizable, or can otherwise be improved. Finding bad code I write notes to myself on what needs to be improved. I make a ticket to fix things. I go fix things, now I have sort of a high level overview of how the different parts of codebase work together. Maybe I have found architectural things to be fixed (this is of course assuming I am better with language/solution space than team I am coming on to but I often am when hired as a consultant) - for example current project I am on had mixed routing and display of components which in this case was bad architecturally (IMHO it's always a problem but in this case it definitely was one) so I fixed that which further made the structure of whole project clear. If stuff I don't understand I ask whoever is leader, don't just change things that you don't understand to be something you understand, there might be reasons why things are the way they are. Now I probably have had a full week on project and done several improvements. Also going through things I might find stuff that relates to the tickets I saw, if I can see that something relates to a ticket I read take that ticket and fix it as part of other stuff doing. All this helps develop overview of how project hangs together and what problems are.

carlmungz 7y ago

Whilst not directly related to this, I have spoken (https://www.smashingmagazine.com/2019/07/javascript-knowledge-reading-source-code/ https://www.smashingmagazine.com/2019/07/javascript-knowledg...) and written (https://www.smashingmagazine.com/2019/07/javascript-knowledge-reading-source-code/ https://www.smashingmagazine.com/2019/07/javascript-knowledg...) about reading source code. If possible (either via docs or guidance from other developers), I find a major API and then follow it to its end point. You will usually come across other major pieces of the codebase this way and you can make a note of them if you wish to do further digging.

ak39 7y ago

I document it. I first read or find out as much about what the code is supposed to accomplish. After this, I jot down the primary aspects of the program I would expect to see - decompose main functions. Every ancillary aspect of the code I meet I put under headings that I have written down. I write down aspects I expected but didn't find. Beyond this, you get a panga blade! Good luck

pizza 7y ago

I recently started working on a quite large C++ codebase and I'm quite a bit more lost at the moment than I would be had I written all the code. I have a strong suspicion that if I just used the right tooling (eg maybe a GUI that displayed some of the flow of the program's state, or something that made it easy to inspect the running program?) it might be a bit easier. Any tips about y'all's favorite C/C++ tools for learning a new codebase?