I’ve never programmed in pair. Two developers sat down in front of a single computer and they code together with one as the pilot and the other, the co-pilot. But in the last weekend I’ve joined in a local event in Brazil organized by my community that mainly studies and practices Agile principles.
During the event, I’ve led a Coding Dojo using Ruby to solve a Fizz Buzz game. That was my first Coding Dojo I’ve ever participated in!
Summarizing… the rules of Fizz Buzz game are like the following:
- If a person’s number is a multiple of 3, he must say “fizz”
- If a person’s number is a multiple of 5, she must say “buzz”
- If a person’s number is a multiple of 3 and 5, he must say “fizz buzz”
- If a person’s number isn’t multiple of 3 or 5, she must say the number.
- If I make a mistake, I drink! This is the best part.
So before the Dojo started, I coded by myself what I thought the final code could be, just for practice.
I got the following specs:
So my own code:
Well. I did it alone, and I thought it was beautiful! Simply beautiful! Why? Because the specs say just the truth. They show us what the code should do. I could read the test and be just fine. Note that the spec descriptions are almost the same as the rules list I showed above.
Then the Dojo began. Half of the participants were new even to Ruby, but were at least a developer in some other language, but none of them was used to TDD.
Anyway, the code began. I started and sat down in the pilot’s chair and I was half coding, half teaching about good practices of programming, especially TDD.
I wrote all the specs, it was enough, but my 5 minutes were gone and I just wrote the first implementation of Game: when the number is multiple of 3, returns “fizz”.
Then a friend of mine took my place and some one in the audience took his co-pilot place. Then after about 1 hour, we’ve got the following production code (the specs weren’t changed).
I was simply amazed: this code was better than mine! If you check this new code, you can read the class just like the bullet list I showed you about the Fizz Buzz’s rules! Fantastic!
Then I was the last to sit in the pilot’s chair, and I improved the code a little bit:
What do you think about this last version of the code?
Yes, we could use “number % 15 == 0″ in the .number_is_multiple_of_3_and_5? method, but we didn’t, we just didn’t think about it at that moment.
But note the main improvements:
I’ve set the methods that use math to private, so the Game class interface just shows what the class should do: run the FizzBuzz game without knowing how it does it.
I have also improved the if/else syntax. Now the Game rules are perfectly readable in the specs and also in the production code! Couldn’t even a non programmer read the production code? Beautiful!
I try to get rid of IF when I code, that’s why my first implementation of the code I did for the Fizz Buzz game had less IFs. But I got rid of the most important: readability, even if it has more IFs.
Thanks to the Coding Dojo dynamics, the code became cleaner and more beautiful, even more so than my first code attempt.
Did the Coding Dojo finish after the event? I’m glad it didn’t!
After showing the code to friends in Webbynode, we refactored the code to the following:
Now we improved the private method names to fit the purpose of our Game! It’s readable just like the last one, but now we can inherit from Game class and create a new game class that uses multiples of 4′s and 7′s if you wish! Have you ever heard about the Open Closed Principle?
In the future, the maintenance would be easier, faster, cheaper and more enjoyable.
This is the power of Pair Programming.