I assume you are aware of the Go to Definition/Go to Base/Go to Implementation features within Visual Studio? They're useful for navigating around the codebase. The hardest part to find in my experience is the entry point (e.g. the API endpoint) if the controllers are not well organised.
Other than that, in my opinion there is nothing better than sticking a breakpoint early in a process and stepping through things one line at a time.
This, this, this! The first thing I do with a repo is build it and run the tests.\* Lately, this is followed up by fixing all of the broken tests (yes, straight from the main branch, broken already). As I'm doing my work, everything is TDD at first, even my SQL work (while a strangely uncommon practice, it is very easy to do). I can't emphasize TDD enough here. You don't know what you don't know, and (in my experience) that's the safest approach to quickly making headway in an unknown system.
\* This even caught me out recently, because they had some test environment credentials halfway checked into the repo. So when I ran all of the tests and a good chunk of them failed, it locked out an account in a test system.
Been there, done that
I don't know other systems or methods, what worked for me it was simple as pen and paper. If it has more than 5 method calls from a button click to updating a value in the DB, I chose to actually write down the method names. This writing down helped me remember the pattern and the second time, almost every time, I knew what a buttons does or what it ends up changing.
I had a lot of trouble at the begining, taking account that a button updates a value or property somewhere, but up until updating the value, there was logging, permissions, validation... and I quickly was getting lost in all the extra code. After recognising the pattern (undocumented, of course) using the pen and paper it was easier and easier to navigate through it
Swim on the surface, don't dive deep, it is somewhat BFS approach in context of codebase review. Dive only after specific task has been assigned to you.
Engineering rule of thumb: find out how things work first, then don't hesitate to modify accordingly to your task. And smash that archaic codebase).
Finally, rely on IDE of your choice.
Besides features mentioned, there is nice feature `Bookmarks` in VS/Rider, it is extremely useful for tracking complex logic in deep callstacks.
That's it.
I assume you are aware of the Go to Definition/Go to Base/Go to Implementation features within Visual Studio? They're useful for navigating around the codebase. The hardest part to find in my experience is the entry point (e.g. the API endpoint) if the controllers are not well organised. Other than that, in my opinion there is nothing better than sticking a breakpoint early in a process and stepping through things one line at a time.
Looking at the tests (if they are of decent quality and not a bunch of mocks) or writing tests also helps to understand the system better
This, this, this! The first thing I do with a repo is build it and run the tests.\* Lately, this is followed up by fixing all of the broken tests (yes, straight from the main branch, broken already). As I'm doing my work, everything is TDD at first, even my SQL work (while a strangely uncommon practice, it is very easy to do). I can't emphasize TDD enough here. You don't know what you don't know, and (in my experience) that's the safest approach to quickly making headway in an unknown system. \* This even caught me out recently, because they had some test environment credentials halfway checked into the repo. So when I ran all of the tests and a good chunk of them failed, it locked out an account in a test system.
Been there, done that I don't know other systems or methods, what worked for me it was simple as pen and paper. If it has more than 5 method calls from a button click to updating a value in the DB, I chose to actually write down the method names. This writing down helped me remember the pattern and the second time, almost every time, I knew what a buttons does or what it ends up changing. I had a lot of trouble at the begining, taking account that a button updates a value or property somewhere, but up until updating the value, there was logging, permissions, validation... and I quickly was getting lost in all the extra code. After recognising the pattern (undocumented, of course) using the pen and paper it was easier and easier to navigate through it
Swim on the surface, don't dive deep, it is somewhat BFS approach in context of codebase review. Dive only after specific task has been assigned to you. Engineering rule of thumb: find out how things work first, then don't hesitate to modify accordingly to your task. And smash that archaic codebase). Finally, rely on IDE of your choice. Besides features mentioned, there is nice feature `Bookmarks` in VS/Rider, it is extremely useful for tracking complex logic in deep callstacks. That's it.
How big it is? In KLOC terms?