Refactoring Spikes as a Learning Tool and How a Scheduled Git Reset Can Help

to learn how complex your code base really is and how much effort a particular refactoring might require compared to the initial expectations, follow these steps:

1. schedule git reset --hard; git clean -fd to run in 1 hour (e.g. via cron)
2. do the refactoring
3. “ wt*?! all my changes disappeared?! ” – this experience indicates the end of the refactoring
4. go for a walk or something and think about what you have learned about the code, its complexity, the refactoring
5. repeat regularly, f. ex. once every week or two – thus you’ll improve your ability to direct the refactoring so that you learn as much as possible during the short time

the exercise has been recommended by kent beck, i’ve just added the scheduled reset because my discipline is not strong enough to resist the likely urge to continue “just little further” and to keep the code if it looks any good. (if i become absorbed in the refactoring so much that i’ll forget to stop on time then i’ll surely also forget about the reset and thus the tendency to just cancel it won’t stand a chance.)

notice that if you do any larger-scale refactoring, it might be pretty wise to apply the mikado method to help you keep track of where you are going and where you are while also keeping your buildable.

when i get to try this out i might write about my experiences here as well.

from http://theholyjava.wordpress.com/2011/11/21/refactoring-spikes-as-a-learning-tool-and-how-a-scheduled-git-reset-can-help/