A coding dojo exercises plan towards refactoring legacy code
My current job at work is technical coach. I’m available for teams that need help to adopt incremental coding practices.
Problems with refactoring legacy code
A few months ago, a team which was struggling with a lot of legacy code asked for help. As you might know if you read my blog, I’m a big fan of Test Driven Development (TDD) because it has made my life as a developer so much more easy. I’m so used to TDD now, that even if I don’t have tests yet (as is the case when refactoring legacy code), TDD helps me :
- To stick to baby steps which are a lot less likely to fail than larges changes.
- Write testable code. I know what testable code looks like, and when refactoring, I’ll try to change it towards that.
That’s why we started to run regular, all team, coding dojo randoris. It was nice for the team dynamics, and the people where learning a lot of technical skills. I also got the feedback that they where not able to apply this directly on their day to day job though. After a bit more discussion, I understood that they did not know where this was going, what to expect, and when !
💡 Test Driven Development also teaches you what testable code looks like.
The coding dojo exercices
It turned out that a coding dojo exercises plan was enough to answer their questions. This is what it looks like.
Drawing
Mind Map
Here is another, more concrete, version, with sample names of katas we can find online.
Text
It starts with simple greenfield katas :
It goes on to intermediate katas, where we can use TDD to do design :
From then on, it’s possible to tackle advanced katas and styles :
- Refactoring fresh code
- Continue design katas on 2 or more sessions
- Always compile Constraint
- Bottom-up TDD
- Game of Life
- Median of a list of lists (with no concatenation)
- Langton ant
- Top-Down TDD
- TDD on algorithms
All this opens the gate to legacy code refactoring katas :
- Gilded Rose
- Race Car Katas
- Ugly trivia game
- Others from http://kata-log.rocks
At that point, the team can mob to refactor production code :
- Real life, static analysis issue, mob programming session
- Real life, code smell, mob programming session
- Real life, larger mob Refactoring
What changed in practice ?
We wanted to split the teamwork and the coding dojos exercises. The team is now doing mob programming sessions on their usual stories twice a week (I’ll blog about that someday). But also doing regular coding dojos exercises in pairs.
Even if they did not go through all the TDD katas yet, mobbing on real stories helps the team to take on legacy code.
Given enough eyeballs, all bugs are shallow. Linus’s Law
Working in pairs on the code katas allows them to be more engaged in the exercises. In the end, it brings faster learning.
💡 A mix of Coding Dojos in pairs and Mob Programming sessions is a good way to teach TDD in a Legacy Code context.
Leave a comment