If the code is tested then refactoring the ideas contained within is the way to go. Do the smallest refactorings possible. Even well-respected programmers who&#x27;ve authored tons of books and given talks do not sit down and 1-shot a program. Elegant programs are the result of refining and designing.<p>The earlier in the development process you get to the refactoring and isolating minimal testable components, the less of a tangle you have between components to refactor; it&#x27;s a lot like the wire tangles we&#x27;re all so familiar with). This not only means less refactoring, but it also means that the existing code is easier to understand.<p>The tests are code. Treat the tests just like the rest of the code. I prefer test-first but if you want to pull your cart in front of your horse then go for it.<p>If the code is not tested I&#x27;d recommend testing it. There are really only 3 options to go from untested code base to tested code base:
- Try to put tests under existing code (often inefficient)
- Refactor the system incrementally as time goes on and features are added and bugs are fixed (slow process but over time test coverage grows)
- Throw it out and start over (ouch but... greenfield; if you do this you should _NOT_ add <i>any</i> new features to the live&#x2F;production system or you&#x27;ll end up in a rat race between the two forever)<p>Also if you&#x27;re able to take any time away (preferably measured in days) the fresh perspective might help too. Sometimes that little bit of total separation is enough to come back and read a method name and wonder why the hell it&#x27;s even in that particular class. This scenario could be an early warning for burnout too, take care of yourself!