Spend 2/3rds of your time adding / updating tests.
(If you can,) involve the original author in code reviews.
Figure out what the original author did right. If the project appears to work, something was done right. Make sure to maintain the right design patterns, libraries, frameworks, testing tools, ect, as long as you can.
Honestly, refactoring is my favorite part of programming. Taking something that "almost" works and turning it into something that's industrial strength and maintainable is what gives me the most professional joy.
(Edit) The last time I was in this situation, the product had very visible problems. I had to put my foot down and declare that they had to be fixed, because no one would use our product if they weren't fixed. If you can point to a problem, like hard scalability limits that management agrees will become an obstacle to company growth, that's your way to get buy-in for refactoring.
Perform small, incremental refactoring.
Spend 2/3rds of your time adding / updating tests.
(If you can,) involve the original author in code reviews.
Figure out what the original author did right. If the project appears to work, something was done right. Make sure to maintain the right design patterns, libraries, frameworks, testing tools, ect, as long as you can.
Honestly, refactoring is my favorite part of programming. Taking something that "almost" works and turning it into something that's industrial strength and maintainable is what gives me the most professional joy.
(Edit) The last time I was in this situation, the product had very visible problems. I had to put my foot down and declare that they had to be fixed, because no one would use our product if they weren't fixed. If you can point to a problem, like hard scalability limits that management agrees will become an obstacle to company growth, that's your way to get buy-in for refactoring.