If I wasn't straight I would propose.
There's no process you might want to do a piece code that isn't aided by it being clean, including messing it up....
Once you've optimised a piece of code, which certainly doesn't necessarily mean you have to make it messy, there is very little else it will do, you've optimised for a task, quite possibly for a task in a particular environment. The most regular mistake isn't premature optimisation, it's reuse abuse. That's when you take your super efficient code and get it to do something else as well. You can't have one piece of code that will do two things efficiently, any attempt to do so will make it inefficient AND messy.
Do a clean version, write the tests, prefereably the other way round, if you are fortunate enough.
Then optimise with your unit tests to prove you haven't broken it, any other approach leaves you with a highly efficient collection of bugs.
Keep your unoptimised version, then when you want to optimise something slightly different or even for something different, that's your starting point.
Optimisation is a lossy process, you lose flexibility, and seeing as in our industry change is a given....
Clean code is efficient, it's optimised for developing.
Keep Up with TechRepublic