Surgically Refactoring with Suture
The next feature means changing legacy code. The estimate just says "PAIN" in red ink. Your hands tremble as you claim the card from the wall.
For all of Ruby's breakthroughs, refactoring is as painful as 2004, when Feathers' book released. It's time we Make Refactors Great Again.
That's why I wrote Suture, a gem to help at every step:
- In development, new code is verified against recorded calls
- In staging, old & new code is ensured side-by-side
- In production, unexpected errors fall back to the old code
With renewed confidence and without fear, you grab the card. You've got this.
This talk will successfully resist the urge of being a walkthrough of features for a library, as anyone can find the README themselves. That said, the talk will be pretty technical and will show meaningful examples and instructions. Most importantly, my goal is to provide proper context for the problem that Suture exists to solve, when it is and is not appropriate, how to use it, and what the road ahead looks like.
Currently, an outline may look like:
- Celebrate the fact that Ruby is full of legacy code, minding the fact that 90% of developers work in legacy code all day, but nearly all tools & training focus on greenfield projects—painting a picture for how happy we'd all be if we just embraced our legacy reality and made things better for the majority of cases.
- Define refactoring (Fowler's definition) and its implications, then define legacy code (where I differ with Feathers' in practice), and explain some of the background: Refactoring to Patterns, Working Effectively with Legacy Code, A/B Testing & GitHub's new scientist gem.
- Identify that the core problem is no workflow or tool attempts to support developers at every stage in the lifecycle: development, test, stage, and production, but that all 4 require roughly the same information, so it makes sense for a single tool to address all these needs in its own flexible way
- (The bulk of the talk) - Walk through a simple-but-not-trivial legacy refactor example, from manually recording interactions to verifying old & new code against them, to running it in a double-entry mode appropriate for staging environments, and finally with production fallback measures until we're certain the change is safe
- Take a brief survey of Suture's massive configuration set: expected errors, custom comparators, time & call limits in testing, and so on
- Discuss side effect detection and other advanced methods needed to make the gem as durable as possible in real-world projects
- Invite the audience to help on the project and to use it in their own practice
1.) First, why the talk is relevant: there are now mountains of legacy code out there standing as a testament to Ruby's success. This is undoubtedly a good thing! But too many Ruby teams are getting the itch to find a new green field to work in (often outside Ruby!)—in part because working with legacy code continues to be so painful. I think this tool & message can help keep Ruby developers engaged & happy working in Ruby.
2.) As for why I'm qualified to speak (and whether this abstract will be backed by a quality presentation), this talk (and the Suture library) are already initially complete and by the time of RubyConf will only have been presented at RubyKaigi. If this talk is accepted at RubyConf, I anticipate investing a significant amount of effort in both the library and the content of the talk, out of respect for the time investment of the attendees.
3.) As for why I proposed the Testing track: while I'm best known in the Ruby community for testing, the reason I've proposed this talk for the testing track is because the traditional approach for performing legacy rescues is all about testing: craft loads of characterization tests, backfill the refactored code with better tests, then discard the characterization tests. This approach can work, but it's exhausting to follow in practice; as a consultant, telling teams to delete their poorly-understood characterization tests is demoralizing due to the high investment they represent.
I'm excited about this tool and this message! On one hand, this talk will to demonstrate aspects of legacy rescue that can be safely automated without custom tests. On the other hand, it will demonstrate how the same tool can extend to deployed environments (A/B testing & GitHub's scientist gem have demonstrated the potential of this, but without consideration for development/test practice).
I'd be humbled to share this story with your audience in the hopes of making life working with legacy Ruby happier and more productive for some of the attendees.