There are many different types of code smells, refactorings, and quality criteria. The goal of this session was to use games to learn several techniques related to refactoring.
All of the games are played with a card deck produced by Industrial Logic, containing green Quality cards, yellow Code Smell cards, and blue Refactoring cards. The deck is fairly extensive – some examples are included below. Each card also contains an explanation of the quality, smell, or refactoring.
Overall, this was a decent, eye opening session that introduced a number of concepts in an interesting way. I do intend to try these with my team and report back on their success!
Game 1 – Rating the value of different types of refactoring using Refactoring War
This game reminded me of Top Trumps. Players have a set of cards of refactoring types, turn over the top card, and rate each one. The player whose card scores the highest keeps all of the cards.
The cards are scored on two criteria: frequency of use and design impact. The team works together to assign a score between 1 and 5 for each criteria and then add them together.
The “war” occurs when the team thinks that two or more cards are of equal highest value. In this case, players holding these cards flip over a new card on top and repeat the exercise.
The objective is simply to get teams discussing the different types of refactoring, get more familiar with the techniques and start to recognize when they can be applied. Without more background in refactoring, the game feels strange the first time it’s played, but over time it would probably be a useful exercise to keep teams thinking about the code that they’re writing and learn to recognize smells and apply refactoring techniques.
Game 2 – Identifying relevant refactorings in Refactoring Hunt
Players study several smelly code snippets and evaluate which of the refactoring cards could be applied to clean up the code. Each card can be applied to one piece of code or set aside if it doesn’t apply to any. Once all of the cards have been assigned, the team reviews the suggested solution.
The objective of the game is to help the team start to recognize how to apply refactorings. There was a lot of disagreement over whether the suggested solution was right, which wasn’t as constructive as it could have been. A better variation might have been to suggest that there;s no “right” solution, but simply let teams compare and discuss their own.
Game 3 – Relating code smells to qualities in Qualitaire
The team lay out the large green quality cards, then decide for each code smell card: “Which quality would be the best fix for code that suffers from this Smell?” Again, once the game is complete, the team reviews the suggested solution.
The objective of this game is to familiarize the team with code qualities, and identify the smells that prevent good quality code. As in Refactoring Hunt, the discussions were the most valuable part of the game, and having a suggested solution caused more disagreement than good discussion.
Qualities: highly cohesive, loosely coupled, no duplication, simple, testable.
Refactoring: Substitute algorithm, unify interfaces, change reference to value.
Smells: Oddball solution, duplicated code, long parameter list, long method, feature envy.
Key points to apply
- The team can learn to refactor in a structured way by familiarization with common code smells, qualities, and specific refactoring techniques.
- The refactoring games are a great way of introducing this information to the team.
- The games would have most value from focusing on discussion of solutions, rather than steering the team towards one right solution.