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.

Related posts

Also in Software development

What’s the difference between blue/green and red/black deployments?

When deploying new versions of a centralized application like a web service, there’s a strategy you can use to direct production traffic to the new version only after it has been successfully de...

Also in Blog

Introducing DevOps to the US Government – Part 2

In the first post in this series, I talked about the challenges for the US Government sector when attempting to introduce DevOps. The sector lags behind others such as Financial Services on every meas...

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...