Refactoring

I am currently building a Tic Tac Toe Board Class, in which I have various methods to update and access squares on the board using a row and column reference. This meant, for example, the method to update a square looked like public void updateSquare(int row, int col, Player player).

The feedback I received was that this interface could be simpler if the squares had a single numeric reference from 1 to 9, so then a square update could just be public void updateSquare(int squareNumber, Player player).

The problem with implementing this change was that I had already started developing a Game Class which used the existing Board Class interface. My approach to this was to comment out both the Game Class and its tests, whilst I updated the Game Class. I then went back to the Game Class and updated it one test at a time. This worked out ok for me on this project but had two major downsides: (1) my pull request which I put in before updating the Game Class had lots of commented out code, which made it difficult to review and (2) this approach just doesn’t scale: on larger or older projects, it’s simply not an option to comment out all code that depends on the interface you’re updating.

Jim pointed me in the direction of this article on “Parallel Change”, which outlines a strategy to deal with the problem, by dividing the change into three phases:

  1. Expand: you add the new interface to the Class, whilst keeping the old in place (hence the interface expands)
  2. Migrate: you migrate all users of the old interface to the new one.
  3. Contract: you remove the old interface.

So now I’ve learnt the lesson, I promise to stop commenting out broken code!

Like what you read? Give Matthew Glover a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.