The Common Threads through AntiPatterns

For a few years, I’ve been developing content and giving talks on the theme of
Rails best practices. This work came together under the name Rails AntiPatterns
in the form of a book, a recent
podcast and
webinar, and some upcoming workshops in
Boston and San Francisco.

Throughout these activities, some common themes have emerged.

Read up on good OO practices

Work on real software

Work with a team that cares about craftsmanship

Follow the Rails commit feed

Upgrade to latest Rails quickly

Many Rails AntiPatterns can be avoided

Last week at RailsConf there were at least three talks that mentioned SOLID prominently, as well as other
principles of clean code and object oriented programming techniques. This is
great to see.

Ruby is a great OO programming language and by following well-proven principles
you can keep your code clean and well-factored.

I think it’s actually refreshing to realize that what we’re doing here isn’t
particularly new or special and that there are proven techniques, learning
materials, and important thought leaders we can fall back on to ensure the
quality of our code and our applications.

There is lots of good stuff out there on principles of object oriented design,
refactoring, and clean code, but here is some good reading and watching.

Many Rails AntiPatterns stem from unfamiliarity with Ruby on Rails

Being the popular new kid on the block, it was inevitable that Rails receive an
influx of developers from other languages and frameworks. Each of these
developers brings with them the techniques, both good and bad that they’ve
learned from their past experiences working with other tools.

This leads to either things being done just plain wrong, such as violations in
MVC, or things being more subtly just
not the “Rails Way”, such as making certain things, like modeling, overly
complex.

The two best fixes for this that I’ve found are continued practice with Rails,
and working on real software with a team of other developers that care about
quality and craftsmanship. Working together, you can help each other identify
improvements to your code via lightweight code
reviews
or Campfire discussions.

An extension of this problem is not keeping up with the changes in Rails itself.
With each version of Rails new features are added and existing features are
refined. If you’re not keeping up with these you’re likely writing more or worse
code than you need to.

Combat this problem by becoming and staying invested in the framework you use.
If at all possible, follow along with the Rails changelog
RSS, even if its only
something you skim.

More importantly, keep your application on the current version of Rails and
upgrade as soon as possible after a new version comes out and someone writes an
“upgrade gotchas” post for this version. Once you’ve upgraded, make sure you’re
refactoring your code to take advantage of new features and syntax changes.
There are other important maintenance benefits to this too, so making the
business case for the time shouldn’t be difficult.

This is particularly relevant with Rails 3.1 coming out soon. If you haven’t
upgraded your application to Rails 3 yet, that means you’re going to be two
important versions behind once 3.1 is released. Some gem and plugin authors have
already started to drop support for Rails 2.x, once 3.1 comes out I think you
can expect the number of gems to drop support for Rails 2.x to increase
dramatically.

The Rails AntiPatterns Workshop

In the Rails AntiPatterns workshops we’re going to sit down with your real code
and we’re going to identify problems and work on fixes as a group. In doing so I
expect that we’re going to touch upon these common threads repeatedly, and we’re
going to call upon proven object oriented design techniques to help improve our
code.

The class sizes are small so we’re going to be able to work directly with each
other and get some real quality time together. I hope you’ll join me.