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

The database in the context of digital transformation

Every company is a software company – Satya Nadella

IDC predict that in less than three years, 60% of global GDP will be digitized, and certainly, most businesses report that they plan to invest he...

Also in Blog

We hope to see you at Oracle OpenWorld Sept 16 – 19 in San Francisco

Oracle OpenWorld is less than two weeks away and we’re excited to be back to talk about Compliant Database DevOps. Oracle OpenWorld is a huge event, which is focusing on bold ideas. There will be mo...

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