RefUcktoring

I should have been in the mountains today and tomorrow and should have been having fun on my snowboard but this night when time came to get up and pack my things I felt that my throat is a bit ill and decided (it was not easy) to stay at home.

What one have to do when staying at home on weekend. I prefer learning, blogging and drawing This time I chosen to write about refactoring, more precisely about my approach to refactoring.
If you’ve been boiling for some time in IT soup you should know a lot of cases when you or your team needed to refactor some complex system. You are lucky if you have the man who built up the current version of the system to do the job but in a half of cases it will be just a dream. In such cases whoever will take the task should be able to:

1. Analyze
2. Plan
3. Implement
4. Test/Debug
5. Fix/Finalize

If the person is not capable to perform any or few of the listed parts of the task – then your project is in trouble.

So, in my project the last week was very hot one since it was last week when we could increment functionality, the next few weeks period will be stabilization phase. And the customer wanted us to improve performace of one thing which required a major refactoring. Not to say that we didn’t knew earlier that the bloody thing should be refactored. We knew that but there were a lot of other tasks + speaking honestly noone wanted to do that job since the guy who initially implemented the complex module (he did this well taking into consideration requirements at that time) was no more in the crew.

But like it always happens the customer insisted and there were no choices but to roll up the sleaves and quickly do the job. I estimated it roughly to 5 man/days.

My programming experience is not that much but I had few times before to lead some difficult refactoring as a manager. And each time I applied the same tehnique which always proves to be good:

1. Analyze
2. Plan
3. Implement
4. Test/Debug
5. Fix/Finalize

For points 1 and 2 you need anything where you can draw some simple diagrams. I use a kind of mind-mapping diagram where I try to desribe at the first level basic tasks definitions, then as the branches everything I know about the problem (but only needed things) and points where I need to research, then on the next levels concrete tasks that I need to implement to get the thing done. This is a very good materialization of the analizys process. All tasks that I need to implement I mark in a red font to have them sharply visible. It looks like this:

I always keep there only needed info, names of the classes, code snippets, etc.
When I feel the analysis is completed I start the point 3: implementation going from top to the bottom of the diagram. When a particular red leaf is done I mark it with green background. I do some small tests after each step and when all is green I start testing and fixing small things that always definitely shows around.

I completed the task in 12 hours almost without any breaks, even missed my lunch. It was interesting and it works
What I actually implemented is incremental loading of data and its caching. Now I know how any abstract caching is done technically. Think this will be useful in future. Big thanks to Max Hryniv who’s code teaches me a lot.
Also I’m not sure that this technique is suitable for everyone. I saw a lot of times when guys skip steps 1 and 2 and start right from the step 3. But almost always it results in UNDERestimation and troubles.