Refactoring is not a Spectator Sport
Posted May 4, 2013 by Katrina Owen
You wade into real-world codebases and find yourself thigh-deep in layers upon layers of cruft left by hasty additions, rushed repairs, and shifting priorities.
This is often the reality of successful, long-lived applications. They have been shaped by immense pressures. If you don’t actively work to improve them, they become stagnant and they begin to rot.
There are books and blog posts explaining how to refactor, but sometimes it’s difficult to reconcile the simple, contrived examples with the reality that we work in every day.
At RailsConf 2013 we wanted to provide a session where attendees program more than they listen. In particular we wished to give people a taste of making a change in a big, complex application by taking small, safe steps.
We prepared a detailed tutorial, which required forking and cloning an application, installing gems, and using Code Climate to explore problem areas in the code base. In other words, it required an internet connection.
What could possibly go wrong?
As it turns out, conference internet is an unreliable thing, and less than 10% of the audience got a good enough internet connection to complete the setup steps.
We quickly devised a Plan B: live coding for 90 minutes. Refactoring is not a spectator sport, except when it is.
We got off to a somewhat rocky start, but it went surprisingly well.
One of the attendees kindly helped me find a pace that worked for the group, and people were active, engaged, and asked questions throughout the session.
After the initial terror wore off, I quite enjoyed the process.
Please give it a whirl and let us know what you think.comments powered by Disqus