24 February 2014
24 February 2014

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 messy, doesn’t follow any sensible coding principles (e.g. SOLID) and is completely untested.

The input to the program is a text file representing a maze. Two mazes are provided as examples in the zipped folder. maze1.txt is an example of a maze where the existing solution succeeds in finding the exit, and maze2.txt, maze3.txt and maze4.txt are examples of where it fails.

Currently the program only outputs the x,y position of the dumb maze walker at each step.

The code is available at https://github.com/geoffbones/CodeKatas.

The task

Your goal is to modify this program to work in all the example mazes, in two steps:

  1. Refactor the code. It should be easy to read, follow the SOLID design principles and be sensibly unit tested.

  2. Extend the program to add a second maze walker which can find the exit in all the example mazes. The existing maze walker must continue to work, even with the addition of your new and improved walker.

You should print out some information to the console for each step made by your entity. Bonus points for making it easy to see what’s going on. Example possible output in output1.txt.

Constraints

  • The only valid movements in the mazes are up, down, left and right. You can’t move diagonally.
  • Both maze walkers, new and old, should be demonstrably correct through unit testing.
  • You must not change the technique the existing walker uses to traverse the maze, i.e. the existing maze walker must traverse the maze in the same sequence of steps after your refactorings.
  • You should version control your changes so that we can view your approach to working with the solution in the discussion group.

How did it go?

All the pairs who attempted the kata focussed on refactoring the code to make it more SOLID rather than using tests to drive the direction of the work. One group had come up with separate classes to implement the walking strategy and walking function, which seemed to us to be a nice distinction.

The great thing was that everyone had managed to find small refactorings, checking in often. Mostly they found they could rely on ReSharper and only occasionally had to refactor by hand.

One group hadn’t made much progress, and they put this down to being too cautious about adding tests at the start before starting to change the code.

Share this post.

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

Related posts

Also in Software development

What learning and development means at Redgate

At Redgate, encouraging personal development in our teams is fundamental to building amazing products.

As well as developing new skills for employees to apply to their current work, personal developm...

Also in Blog

You’re ready for DevOps, but is your workplace?

DevOps is gathering pace. More and more organizations are recognizing that by encouraging collaboration, cooperation, and communication, they can release features faster and offer advantages to custom...

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