This is an interactive, remote-friendly workshop that teaches refactoring.
The overall flow of the workshop goes like this:
- (10 minutes) Facilitator gives a presentation defining refactoring and code smells.
- (15 minutes) Participants individually identify specific structural problems in a 70-line Ruby file, posting their observations in a chatroom.
- (2 hours) Participants ensemble-program to fix one problem at a time, with the facilitator typing code and promoting discussion.
- (30 minutes) The group debriefs with another presentation and time for questions and discussion.
- You'll need a facilitator with strong refactoring skills.
- You'll need some way of video conferencing and collecting participant suggestions in a chat log. I've used Zoom for this.
- In theory, the workshop should scale up to many participants (dozens? hundreds?) but I have not tried it on large groups yet.
- I recommend you use IntelliJ or RubyMine as your editor. You'll need a paid license, or the program will quit every 30 minutes. Other editors will work, but I haven't used one with better support for refactoring and tests than RubyMine.
The goal of this workshop is to practice removing code smells via small, targeted refactorings, using frequent test runs as a safety rail. The emphasis is on the practice of refactoring, i.e. safely and incrementally changing the design of code without changing its observable behavior.
A breakdown of the goals:
- Persuade participants that...
- refactoring is a mutually beneficial activity, furthering the goals of individual programmers, the team, the company, its customers, and the users of the product.
- you don't need to have the perfect design in mind before starting to refactor.
- you do need tests before you can refactor safely.
- Give participants time to practice...
- identifying code smells.
- focusing on one refactoring at a time.
- incrementally improving a codebase, avoiding big-bang rewrites.
- using the language of code smells to discuss design tradeoffs.
- communicating the motivation for a change in Git commit messages.
- making backwards-compatible changes to an interface (e.g. creating a class to hold formerly global methods, leaving the existing global methods as middlemen).
- Demonstrate...
- getting fast feedback by running all the tests after every change.
This workshop can't do everything—after all, we only have three hours. Some things we're intentionally not going to cover:
- Writing tests. The example code comes with tests, which are supposed to be complete. The facilitator should communicate to participants that he/she trusts the tests and will not need to add more.
- Refactoring test code. If the group ends up looking at the test code for any reason, the facilitator should mention that the tests are not exemplary, but that refactoring them is out of scope. Refactoring tests presents its own set of pitfalls, and we'd rather not address them in this workshop. It might be worth pointing out to participants that the tests do not have to be pretty for refactoring to work. They just have to fail when the code has a bug.
- Fixing bugs. The participants might find bugs in the code, or behaviors they think should be changed. The facilitator should remind them that the goal of refactoring is to hold behavior constant while changing structure. By making the bugfix or feature change later, in a separate commit, we'll more clearly communicate our intent to programmers who work on this code in the future.
See FACILITATING.md
- Code Smell: "a surface indication that usually corresponds to a deeper problem in the system". Source: martinfowler.com
- Refactoring: (noun) "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior". Source: refactoring.com
- Refactoring: (verb) "to restructure software by applying a series of refactorings without changing its observable behavior". Source: refactoring.com