May 8, 2010
Mastering Refactoring & Clean Code Through Peer Group Learning & AssessmentI hear an adventurous few of you have been trying the TDD Peer Group Learning & Assessment model I presented at QCon earlier this year. It's proven to be successful, in practical terms (i.e., improved code quality) within TV Platforms at the BBC and a couple of other pilot sites over the last 18 months.
The BBC pilot group completed their TDD assessments last summer and have moved on to the more demanding discipline of refactoring (although some basic refactoring was, of course, required in TDD). To make this work, we extended the model we applied on TDD to guide us in getting a good balance of experience across a range of code smells and the refactorings we believed we should be applying to them.
In the refactoring orientation, the pilot group selected 10 code smells they recognised from their own code and researched refactoring strategies for eliminating them. They demonstrated their strategies and we made a list of all the specific refactorings (and compound refactorings) that were applied.
At the end, we had a matrix of code smells and refactorings which indicated which of refactorings we applied to which code smells, based on the demonstrations and reading we'd done.
An example Refactoring Matrix
The pilot group has ben pairing just as they did when they were practicing TDD. They watch each other to ensure agreed refactoring good habits are being observed, and sign each other off for up to a maximum of 4 habits in each pairing session (minimum one hour each way).
An example Refactoring Worksheet listing agreed good habits to observe
They have also been ticking off the appropriate box in their refactoring matrix, so they can see if their are any code smell/refactoring combinations they're not getting experience of. It helps them to plan each practice session by deciding what code smells they'll be looking for in the session. Ideally, they find example code smells before the session.
The ability to detect code smells is part-and-parcel of the refactoring discipline. Code analysis tools like CheckStyle and XDepend help enormously in code bases of any appreciable size.
As well as working on their own code, members of the pilot group have created refactoring "scratching posts" - code snippets with known smells, or open source code that is known to contain many good examples of code smells in their matrix. It's useful to find code that is not too smelly and that has just enough automated test assurance, so you're not wasting most of your pairing session dealing with complicated architectural issues or writing complex unit tests to get coverage. A great refactoring scratching post that the pilot group found is Apache-Commons-Math. It's actually quite easy to understand, doesn't rely on libraries and frameworks outside of core Java and has pretty decent test coverage. But it has many, many examples of all the code smells in the group's refactoring matrix, and many variations to widen the learning experience beyind simple, formulaic refactoring.
Because checking in is part of the discipline the group have agreed on, they've taken personal branches of their "scratching posts". We're finding that it's useful to "bottle" code smells in SVN so people can go back and practice on interesting examples that have been eliminated from production code. (Otherwise, there's actually a real danger of "running out" of examples of a particular smell as practice sessions work their way through a shared code base).
Members of the group have come on leaps and bounds in their basic refactoring skills, but they tend to all agree that they feel they still have a long way to go. I would agree. Refactoring is hard to master. It really tests pretty much all of your knowledge and ability as a programmer. The more general, abstract skill of figuring out how to get from code as it is now to some desired architecture is a big step forward that the pilot group has yet to make. For now, it's a major step forward to be able to identify common code smells and apply a simple sequence of refactorings. In reality, that puts them way ahead of the curve, since very few programmers even manage that.
I liken it to snooker (no, not golf this time). Right now the pilot group are learning to pot reds, and maybe follow up with the occasional colour if the opportunity arises. The next step in their journey is to learn how to do longer breaks - how to pot balls whilst lining up the next shot. Once they have mastered the fundamental vocabulary of refactoring and code smells, we will work our way on to sentences and even paragraphs. This will be a longer process, but I believe it will put them right at the top of the curve (and me, too, since I'm not much far beyond mastering the vocabulary myself - indeed, very, very few - if any - actually are).
So here's my challenge to you, dear reader. I contest that the people who are practiced to the point where they've internalised all the basic refactorings and can sniff any code smell a mile away, and have progressed to the point where they can think half-a-dozen or more refactorings ahead (like a chess grandmaster) and do refactoring at an architectural scale will truly be masters of Clean Code. I don't believe such people currently exist. But I also don't believe that it's because it's not possible. I think it's eminently possible. I just think we are among the first people to really try.
Posted 1 week, 2 days ago on May 8, 2010