Code reviews shouldn't dwell on style issues that can be handled by linting. To the extent that you can automate some of the review process, and prevent sloppy commits from being merged in by having them fail CI, you'll eliminate part of the problem. Another thing that helps is reducing the semantic distance between what a commit message says a commit does, and what it actually does. This is pretty easy to enforce relative to more subjective aspects of coding. The last thing that can make a big difference is not getting hung up on wanting to rewrite a commit as you would have written it, but focusing on improving understanding and clarity for whoever will inherit the code next. If there are serious issues with the architecture and patterns the code is using, CR can be too late in the process to address them effectively (depends on the scale involved). I'd try to collaborate with other engineers earlier in the process to help set them on the right path [1].
As for unit tests, make sure to isolate the unit (generally a class or function), and test its interface. Tests that are coupled to the implementation aren't as useful. Investing in writing unit tests now will increase your velocity in the long run. You'll be able to take on more technical debt in the short term with better terms, so to speak, since you'll have a robust test suite to refactor against. Obviously, this doesn't mean you should write bad code, but this will give you the option of considering performance and reusability tradeoffs if you need to hustle a feature out the door.