I frequently refactor my code and legacy code. Why should I be scared of refactoring ?

I see refactoring as analogous to balancing my budget. Inevitably expenses are added, so I'm always looking for strategies to make it leaner. If I don't refactor code, I'll likely go "overbudget" - the code will be cost-prohibitive to maintain.

The time I find best to start the refactoring process is the day after I get the code passing all tests; I still understand all the nuances of the problem-space, and I still remember the reasons I used particular flows and structures. At that point I comment the code with data-flow and reentrancy assertions and write tests to reflect those assertions, then fiddle until the code passes the existing unit tests and the new assertions.

1 week after that, I go in as if I'd never seen the code. I do speed and memory profiling. I try to imagine various new scenarios for use of the code (in whole or in part).

If the code needs refactoring for efficiency, I do it as a matter of policy - by that point I've already done most of what's necessary to make such a refactoring successful.

If the code could be refactored to make it more flexible for re-use, I examine my schedule to see whether the refactoring is likely to take up more time than I have available in the short term. If I don't have time, I'll re-evaluate again in 1 week. Otherwise... refactor!.

I hope this exposition has not been overly boring.

-David