Well, I'm just going to assume there are no tests surrounding the code. As a newcomer, you're going to be fairly unfamiliar with how things work, so one of the things you could do write tests that assert existing behaviour. This gets code under test, gets you familiar with how things work right now, and gives you a base from which to refactor.
In general, an "if it ain't broke, don't fix it" approach is the pragmatic one in your situation, but but there are going to be times when stuff is broken and needs to be fixed. In that case, you might expand the scope of the fix to include a refactor of that specific component. The peril there is when your refactor starts to sprawl unnecessarily or excessively. If you feel like maybe your refactor has begun to necessarily expand its scope beyond what you anticipated, it's time to re-evaluate just how pragmatic it is to refactor at all.