I always imagine new code bases like new unexplored regions of a foreign land :)
One thing I've learned as a mountain trail runner is that you first need to know the cartography to make an educated guess on the direction you need to take to reach a particular goal.
Reaching the top of an elevated spot is usually the way to go first, then you'll worry about the right directions and the small details along the way until you reach your goal (like a large river or a bottomless ravine)
So it depends on the code base but I normally try to use an UML class graph generator to have a bird eye view of a code base.
That way, you'll get to really see some part of the logic flow and you'll be able to imagine the data flow as well.
Just like Mark said, debugging is also a great, if not the best, way to explore a code base; leave log trails around to see where the data/logic goes.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I always imagine new code bases like new unexplored regions of a foreign land :)
One thing I've learned as a mountain trail runner is that you first need to know the cartography to make an educated guess on the direction you need to take to reach a particular goal.
Reaching the top of an elevated spot is usually the way to go first, then you'll worry about the right directions and the small details along the way until you reach your goal (like a large river or a bottomless ravine)
So it depends on the code base but I normally try to use an UML class graph generator to have a bird eye view of a code base.
That way, you'll get to really see some part of the logic flow and you'll be able to imagine the data flow as well.
Just like Mark said, debugging is also a great, if not the best, way to explore a code base; leave log trails around to see where the data/logic goes.