Do you want to know something that works really really well for me? I spend the first 10 to 15 minutes of the day reading the code I (or we) wrote the day before. I always find out something to change. It’s often a rename or a method extraction, something that I can apply quickly and safely, most of the time using the automatic refactor tool at hand. I review both, the production code and the tests, to see if the tests really document the behaviour of the system. The effort is insignificant and the benefit in the long term is huge. This is the low hanging fruit, a nice way to reduce accidental complication. This exercise let me learn about myself, my way of thinking and designing, providing me with immediate feedback to improve the code. It’s like travelling to the past to prevent problems before they really happen in the future. It also helps focus on the code. This exercise is way better when done in pairs – let your new pair give you feedback about what your previous pair and you did yesterday.
Apart from the source code, I do refactor the documentation. Documentation?! Yes, I do write documentation and comment my code. I will write another post on this. However I never comment what the code does but rather the “why” and “why not” – why is the code in there or why did I discarded some other implementation.
Refactoring is somehow similar to dish-washing. When done often, it takes very little time and effort.
When you haven’t done it in two days you don’t see the right moment to start off, you look at the pile and feel lazy. You blame others for using so many cups… do they really have to drink so much tea?! – even when it was yourself!
If you haven’t done it in a week, you just consider buying new dishes and throwing away the entire pile.
Sometimes I decide to spend more than 15 minutes, I’d say that at least once I week I spend about two hours purely refactoring. I call this session “refactoring to infinity”. I start out with the easy wins but soon I search for duplication, coupling and other design problems. I ask myself whether the code is really modelling the business domain properly. And I keep on refactoring until I can’t find anything more to change. It doesn’t mean the code is perfect, it just means I don’t know how to make it better given my current understanding of the domain and skills. This is why I want come back later, because we use to learn about the specific details of the domain as we go.
Refactoring always pays off, except when you introduce unnecessary complexity. Be careful, do not employ the Open/Closed principle until the new requirements turn out to be easier to implement upon code previously opened for extension. This is, consider YAGNI before.