When I open an unfamiliar codebase, the first temptation is to rename things. I try to resist it. Names that look confusing may be the vocabulary of a business process I have not learned yet. Reading a real request usually teaches me more than browsing every folder.
Build one reliable explanation
I choose a small user action and follow its data until I can explain the observable outcome. I compare that explanation with logs and a person who uses the system. When the story does not fit, I revise the map rather than assuming the implementation is wrong.
Understanding grows faster when each assumption can be checked.
Only then do I look for a change that makes the next investigation easier. A clearer boundary or a focused test can be enough. The aim is not to make the code look familiar immediately, but to leave a dependable path for whoever reads it next.