Team Refactoring Exercise: The Gilded Rose
96 views
Skip to first unread message
George Paci
Aug 31, 2012, 11:11:20 AM8/31/12
to agile-coach...@googlegroups.com
All,
At Agile2012, Arlo Belshee (and others) led a group refactoring
workshop focused on a particularly gnarly, well-contrived body of
example code called "The Gilded Rose" (after an inn in World of
Warcraft). I think the code is by Bobby Johnson. [1]
The scenario (mostly covered in the example's README file) is that the
inn's inventory tracking system needs a small update to accommodate a
new type of item. The original coder has left a comprehensive suite
of tests -- of the symbol "true". Higher-level tests are left as an
exercise for the people doing the, uh, exercise.
The ground rules for the group refactoring are pretty simple:
* The code is displayed on a big screen, legible to all.
* There's a rotating typist role; the typist can't make suggestions.
* Everyone else suggests refactorings and tests, and figures out which
one to do next.
* The typist keeps saying, "Speak in line numbers, guys: pointing to
'that line' is supremely ineffectual communication."
To do something similar with my team, I translated the original code
from C# into Python [2] (*), and held a Brown Bag Lunch on Wednesday.
After fiddling with the wide-screen TV and waiting for everyone, we
had around 45 minutes to do the exercise.
I took the typist role first, since the point is for the team to do
most of the thinking. I restrained myself to pointing out duplication
and mentioning categories of refactorings (such as "Extract Method",
"Extract Method", and "Extract Method"). Later, as one team member
came to dominate the discussion, he became the typist.
I was kind of disappointed by how far we got, and by the fact that the
one 33-line method of interest never got broken up into the three
methods it was so clearly crying out to be. We never did get to the
point of implementing the new feature, but it definitely would have
been easier with our refactored code than with the original code.
Some refactorings that I just reach for instinctively didn't seem to
occur to the rest of the team (or at any rate they didn't mention
them): pulling a loop body out into a method, making self.items[i] an
argument to a method to make things more readable, moving behavior
that exclusively concerns Items over the the Item class. Maybe I need
to do a lecture-type Brown Bag Lunch about common refactorings.
Also, even though we spent several minutes reasoning about a tricky
part of the code, nobody even suggested writing any automated tests.
Or, for that matter, running manual ones, even though we had text
output we could visually check.
I spent the beginning of the session fiddling with the technical setup
(the big-screen display, the IDE's font size); I wish I had instead
taken that time to:
1) emphasize what the point of the exercise was,
2) mention the importance of testing, and run the test suite once,
3) go over a list of common refactorings,
4) encourage participation.
On the bright side, most of the developers were interested; even the
quiet ones had some suggestions for how to improve the session when I
talked to them one-on-one later that day.
I'd recommend doing this exercise on your own team; about an hour
seems to be a good time frame. If you work in some other language,
translating the Gilded Rose code should be pretty straightforward --
about a half-hour's worth of work.
I'm also asking for your feedback about my experience as described
here; I'm trying to be a better coach every week, and any advice on
the people side of things is more than welcome.
--George
A superior pilot uses his superior judgment to avoid having to
exercise his superior skill.
(*) In all seriousness, simply translating it into Python improved its
readability significantly. Semicolons? Curly braces? Parentheses
around every if's condition? A Jedi craves not these things.
Lior Friedman
Aug 31, 2012, 11:31:56 AM8/31/12
to agile-coach...@googlegroups.com
Hi George,
thank you for sharing.
We used the Gilded Rose to do a testing Dojo in xp2012 (led by Emily Bache).
it was much fun.
The point of that dojo was to write end to end automated test for that code example using any tool we could think of.
The nice thing is that Emily shared an implementation of the code in various languages
which can be found here:
Lior
Reply all
Reply to author
Forward
0 new messages