24 February 2014
24 February 2014

Code kata 3: Refactoring

The kata

This kata was inspired by a truly ugly piece of code we came across in Redgate Towers. It had a whole bouquet of code smells: long methods, a lot of indentation, static variables, inconsistent naming, code that was duplicated with small modifications, and a couple of small bugs. And, gloriously, it was just a few hundred lines long and carried out one clear, isolated function. We saw it and realised in an instant that we were looking at the ideal material for a refactoring kata.

Rather than just ask the participants to refactor the code, we put the emphasis on writing unit tests, with the idea that this would drive the need to refactor.

The task

Your job is to write unit tests for the code, refactoring the code to create testable units.

  1. Keep your check-ins small by limiting each one to a single refactoring.
  2. Should you find any bugs, fix them as you go by creating a failing test and then making it pass; then return to refactoring.

How did it go?

We find it curious that, even though we had quite a few pairs who attempted the problem, all of them appeared to struggle with the thorny issue of what’s the first thing you’re going to change, when there aren’t any tests?

A number of groups tried to write tests for the module’s current behaviour, and then refactored ensuring the tests remained green. Their problem, though, was that they ended up with tests for behaviour that was obviously broken, and you had to wonder how useful these were.

Another group started out using ReSharper refactorings, assuming – and we would agree with them – that they were safe to do without tests. Their idea had been to switch to writing unit tests as soon they could, but the way things turned out, lunchtime appeared and they never wrote any tests at all, showing perhaps how hard it is to stop once you’ve set out in a particular direction.

On reflection, we feel that a better approach might be to refactor to remove the static variables first, as we think these presented the greatest obstacle to separating the code into testable units. It would be interesting to see if the results are more promising if we were to set the same kata again, giving this as the first step.

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in Software development

SQL Server Configuration — the Redgate survey results

In the Foundry Team at Redgate, we’ve been looking into how data professionals manage the complexities of their wider data estates. One aspect of this is configuring, deploying and monitoring dr...

Also in Blog

Easing the transition from shared to dedicated database development

Working in dedicated development environments for the database is the ideal for many. This is the message we frequently hear throughout the industry from thought leaders, at conferences, and in many w...

Also about Code Katas

Code kata 7: Producer-consumer problem

First, apologies for nodding off and not posting for the last few weeks. I have the usual set of excuses, which you can guess easily enough without the need to read them here.

So, on to the kata: som...

Also about deliberate practice

Code kata 2: Amaze me

The kata

You are given a program which is capable of traversing 2D mazes. However, the solution isn’t perfect and fails to find the exit in certain types of mazes. Moreover, the current solution is...