That being said, one of my tenets when writing software and applications is to write clean, maintainable code. I know that in six months time, I'll be coming back to that code snippet or that method, and I want to make it easy for myself to remind myself what I had been doing and why I took a particular action. My goal is to write such that my future self won't curse my past self for writing an unmaintainable mess.
In my professional career, I've worked primarily on four different codebases. It has honestly been fascinating to compare and contrast general coding styles, methodologies and architectures. One application has/had resource management issues towards the beginning of development. Another has/had hard-coded paths in the codebase. Another suffers/suffered from being stuck on an older PHP framework.
One thing that I've done to address problems with a codebase is to make small code changes that improve it. Perhaps it's a change to a PHPDoc. Maybe it's declaring variables before attempting to use them. It could be fixing how a class is capitalized when it's used (e.g. an "Instantiate" class referred to as "instantiate" in the codebase) It may be splitting logic into a separate method.
If these changes are made in separate branches (for Git), it keeps code review manageable. The worst thing to have, when reviewing code, is to see multiple fixes all at once, touching all files!