'Addressing' can be ambiguous. Writing comments to explain why it's right and needs to be this way? Or changing the code without considering if they have enough knowledge of the rest of the codebase.
There's also a chance it's not understood yet to easily explain it.
A key part of joining a team is remaining open to the fact that just because I don't understand something, doesn't mean there isn't understanding in it.
Sometimes there's understanding, sometimes the person who did understand has left the team. This is why it's worth writing good commit messages and going back to read them when there's a funny piece of code. A lot of my commit messages are to the effect of "I did it this way to be backwards compatible with how it always worked. It still looks funny to me though"
Then at least future person knows I don't have a good reason for it and they can dig deeper or get PMs to sign off on something better if they want.
Reading code is harder than writing it, and too many people don't have the patience for it.
Instead, in cases like these they'd rather invest the time re-learning the lessons of the past because they thought it should be a certain way, and if they can't instantly see a reason why it's done a certain way, then they behave (unintentionally or otherwise) as if understanding is not possible.
Especially where it's tricky it's worth including a larger pre-amble in the code itself, as well as source code control.
Often one or the other are suffering, and it's sometimes worth giving a description of how the components work together in detail, or are relied up on by more than one use case (therefore not a simple change or solution).
There's also a chance it's not understood yet to easily explain it.
A key part of joining a team is remaining open to the fact that just because I don't understand something, doesn't mean there isn't understanding in it.