litany against fear

RailsConf 2009 Working Effectively with Legacy Rails

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is from Pat Maddox and BJ Clark.

Why? Rails is almost 5 years old, plenty of value to be made and everyone writes it. What is legacy code? Code that’s a few months old maybe? Plenty of defintions: “Code without tests” “accumulated technical debt” “code that is difficult to change”

Technical debt is not necessarily bad…it’s deferring necessary work. Plenty of examples abound: Rails, MediaWiki, ActiveScaffold, all of the code you write on a daily basis. How to figure out where debt exists: easy upfront gains, bad migration paths, difficult to extend. There’s ways to deal with this though: big design up front, or agile.

TATFT. The cycle is of upmost importance. People seem to forget about the refactoring part once tests are passing…don’t miss it!

Testing is the best way to minimize debt that someone else didn’t pay down. Must maintain the existing value along with adding new value. Start testing NOW. Unit tests are extremely important, and Cucumber is awesome for testing the entire stack. When should you test though? Don’t do it all at once…do it just in time when you actually need it. Isolation is really helpful for injecting testing in applications. The more split up parts are, the easier it is to test individual sections.

Let Rails do its job. Plenty of places where code is rewritten: caching, validations, serialization, memoization, and so on. One way to deal with this is make everything a framework, use metaprogramming and DSLs to your advantage. Some pros: it’s easy to read and the behavior is free. On the flip side: it’s not as accessible to brand new Ruby programmers. Write your own little framework or use someone else’s like resource_controller.

Rails also has plenty of extension points that you should be using: filters, observers, callbacks. Callbacks are great for cleaning up controllers and pushing logic into the model. The main problem here is the indirection when trying to debug, and also testing is a bit harder. However, it’s practically like using a transaction and it keeps with the skinny controller/fat model standard.

Ruby seams: alias_method_chain, method_missing, send / eval. Plenty of places where you can modify code without modifying the actual text you’ve written. A good idiom to use is default arguments, which is great since classes can be used here as well. Mocking can help out as well with faking out parts of legacy code bases that won’t help with testing what you need.

What’s really essential is to understand Ruby as much as possible. Learn to make Rails work for you. Another awesome reference is “Working Effectively with Legacy Code” by Michael Feathers.