I've been occasionally criticized since my Make Ruby Great Again talk that it's been a while since I'd contributed much to the Ruby community. I was thinking about this when I was asked to design a talk for Ruby Kaigi (Japan's national Ruby conference) that was about something other than testing or feelings. (This forced me to consider whether I knew anything other than testing and feelings.)
I sat on the idea for a while before surmising that the greatest risk facing Ruby teams' continued use of Ruby was not only whether Ruby was fast enough or concurrent enough, but whether their existing applications were maintainable enough. The most common reason I've seen teams leave Ruby for has been the lack of tools and education needed to work effectively with large, complex applications. (New languages are appealing, but new languages with which you don't yet associate with tremendous pain are even more appealing!)
Regardless of language, when saddled with a hard-to-change codebase, the grass of a total rewrite will seem greener. But Ruby's dynamic nature gives us fewer tools than some other language ecosystems for successfully managing the invetible accretion of incidental complexity that every long-lived system faces. Is there anything we can do to make legacy Ruby more maintainable?
That question led me to this talk. In it, I introduces a new gem that we designed to help wrangle legacy refactors. It's called Suture, and along with providing some interesting functionality to make refactoring less mysterious and scary, it also prescribes a clear, careful, and repeatable workflow for increasing our confidence when changing legacy code.
This talk's slides are available on Speakerdeck:
Here are links to a some of things I referenced in the talk, in roughly the order they appear:
- Yaboton misokatsu
- Refactoring: Ruby Edition
- Eclipse's Java Refactoring Tools
- Working Effectively with Legacy Code
- Jim Weirich
- Gilded Rose Kata