When working with teams who are new to refactoring I like to help them practice techniques with code katas. A favorite of mine is one that I call The Code Smell Scavenger Hunt Kata. It gives development teams the opportunity to practice identifying and refactoring code smells in their own codebase.
It’s worthwhile to work this kata into the team’s practices if:
Early on I recommend tailoring each session around a specific code smell. As the team progresses, the kata can become more freeform to allow the team to find any of the code smells that are present in their code. Use Chapter 3 Bad Smells in Code from Martin Fowler’s Refactoring book as a guide. It is that chapter, co-authored by Kent Beck and Martin Fowler, that lists out code smells and refactoring techniques to remedy them. Choose a specific code smell from the chapter as the focus of the kata. I try to start with the smells that are easier to identify or ones that we have already discovered and discussed in the team’s code.
Recently, I’ve been creating a handful of slides to describe the code smell and kata. In the slide deck I describe the code smell, why it’s a problem, and signals in the code that help to identify the smell. I’ll then describe the specific refactorings used to address the code smell. Finally, I describe any “exceptions to the rule.” Since code smells are heuristics, I like to describe cases when we may choose not to refactor, if that’s applicable to the code smell.
If the slide deck feels too formal for a code kata feel free to forgo it in favor of covering the topics in a conversation.
Before starting it’s important to make it clear that these refactorings are for practice only. We will be scratch refactoring, practicing a refactoring and throwing away the changes at the end of the kata. The team may leave with some ideas around how to clean up the code the next time the work takes them there, but it’s important not to commit these refactorings to version control. We’re trying to maximize our learning and practice time in the kata, and as a consequence, we’re not spending time making the code production-ready.
It is important to remind the team that refactoring workflows rely on running tests between each micro-step of the refactoring. This ensures that behavior hasn’t inadvertently been modified. However, the focus of this kata is identifying the code smell and the mechanics of the refactoring. Since we often do these kinds of katas in codebases that have spotty (if any) microtest coverage, we don’t spend time trying to get the code under test or writing characterization tests for the code. If this is a concern, you can find refactoring katas that come with tests (the Gilded Rose Kata for example). Or, you can practice other katas focused on characterization testing legacy code. I practice both types of katas with teams, emphasizing the different aspects of refactoring.
Once the team has an understanding of the code smell and the refactoring steps we begin the kata.
When closing out the kata have the team discuss what they have learned, what they liked and disliked about the refactorings, and what things they might do differently the next time they encounter similar code.