Refactor checklist
- Read the file
- Take notes, add comments to explain the functionality
- Write passing unit tests
- Create a new file
- Switch unit tests to work on the new file
- Rewrite feature from scratch
This way you're not stuck thinking through the problem the same way, and only care about the end result.
Bonus tips
One file at a time
This way you can ensure that your unit tests are still passing and you can finish it in it's own commit with passing tests before continuing on.
Commit each file's refactor in its own commit
This ensures that it's really easy to go back in the history and find out exactly when and how the files were changed.
Also be sure to add the file name in your commit message for easily finding the commit with the changes in your pull request.
Don't overdo it
The goal is readability, not less code. If it's more code for more readability, leave it as is.
One of the most challenging problems to solve on your team is communication and intent, and showing off a complex function in a tiny one liner script is rarely the best way to do that. That's the equivalent of abbreviating things all the time - annoying.
Stay consistent
Ideally, your team will program in a similar style, such as "functional", "imperative" (ugh) and have your own lint/formatting configuration, conventions and rules.
It's important to make each application read like a book from the same author.
Remember that you'll do it again in the future
The code you write today will probably upset you in the future. Follow the steps above to keep that to a minimum, but just know that just like in life, you'll never be done refactoring - so just learn to enjoy it! SL