I attack it pretty much the same regardless of language or project. Generally, I start with the product, see how it works, find the 3-4 most common workflows and get a handle on them.
Then I like to check out the database (or algorithms & data structures if no db) and see how data is stored and manipulated, usually tells you a lot about choices that have been made.
Then open the project(s) and trace those 3-4 workflows once I understand it from the top level workflows. Part of this is also of course, getting the project(s) loaded and building locally as needed also reviewing tests, CI/CD, dependencies etc.
Lately, I've used Claude Code to help me with this, have it build a function map or class map and have it breakdown key insights about the code and trace those few workflows for me that I then validate. My process is pretty much the same just Claude does a lot of the initial lifting. I'll also dump the entire DDL for most databases (if they are more then a few tables) and send it to Claude and use that as a way to look for patterns/issues etc. For older monolith apps I've had to break the DDL into chunks sometimes just because some of these older apps have a very large number of tables/indexes/constraints etc that have been added over the years. Same thing works for json stores too fwiw.
Assuming you have a c or cpp project: compile and build it first , run the tests if any.. and run cscope or equivalent on code you want to change first.
Yeah, that's ok.
But if I am completely unaware about the code, I don't know what to search in cscope, or anything about the flow of the code. How do we manage in that situation?
Do you have a specific task you need to do in this code? If so, search for something related to whatever that is - text from the UX, data, fieldnames, etc. Once you find one spot in the code related to your task, follow the code back and forth to figure out that feature.
And if you have no task you are aiming at, find the main entry point of the code and start tracing where it goes.
But either way, I would not actually start with the code. The code glues together the data and the UX, so go figure those out first. Use the app. Browse the data schema. Figure out some connections. Once you understand that "datum A" is used in "UX widget B", the code just becomes a middle point to step through to connect them. And stepping through it once for one data field will likely teach you the patterns used in the codebase, so you can apply that learning to everything else.
And don't forget to read documentation. It isn't always kept up to date, but something is better than nothing.
I attack it pretty much the same regardless of language or project. Generally, I start with the product, see how it works, find the 3-4 most common workflows and get a handle on them.
Then I like to check out the database (or algorithms & data structures if no db) and see how data is stored and manipulated, usually tells you a lot about choices that have been made.
Then open the project(s) and trace those 3-4 workflows once I understand it from the top level workflows. Part of this is also of course, getting the project(s) loaded and building locally as needed also reviewing tests, CI/CD, dependencies etc.
Lately, I've used Claude Code to help me with this, have it build a function map or class map and have it breakdown key insights about the code and trace those few workflows for me that I then validate. My process is pretty much the same just Claude does a lot of the initial lifting. I'll also dump the entire DDL for most databases (if they are more then a few tables) and send it to Claude and use that as a way to look for patterns/issues etc. For older monolith apps I've had to break the DDL into chunks sometimes just because some of these older apps have a very large number of tables/indexes/constraints etc that have been added over the years. Same thing works for json stores too fwiw.
Assuming you have a c or cpp project: compile and build it first , run the tests if any.. and run cscope or equivalent on code you want to change first.
Yeah, that's ok. But if I am completely unaware about the code, I don't know what to search in cscope, or anything about the flow of the code. How do we manage in that situation?
Do you have a specific task you need to do in this code? If so, search for something related to whatever that is - text from the UX, data, fieldnames, etc. Once you find one spot in the code related to your task, follow the code back and forth to figure out that feature.
And if you have no task you are aiming at, find the main entry point of the code and start tracing where it goes.
But either way, I would not actually start with the code. The code glues together the data and the UX, so go figure those out first. Use the app. Browse the data schema. Figure out some connections. Once you understand that "datum A" is used in "UX widget B", the code just becomes a middle point to step through to connect them. And stepping through it once for one data field will likely teach you the patterns used in the codebase, so you can apply that learning to everything else.
And don't forget to read documentation. It isn't always kept up to date, but something is better than nothing.
[flagged]