- 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.
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.
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.
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.
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.
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