---
title: The Common Threads through AntiPatterns
teaser:
tags: news,web,good code
author: Chad Pytel
published_on: 2011-05-24
---

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](http://www.informit.com/title/0321604814 "Rails
AntiPatterns"), a [recent
podcast](http://www.engineyard.com/podcast/engine-yard-cloud-out-loud-s01e22-chad-pytel
"Engine Yard Cloud Out Loud S01E22: Chad Pytel") and
[webinar](http://www.engineyard.com/video/23692281 "Rails Antipatterns - Open
Session with Chad Pytel"), and some upcoming workshops in
[Boston](http://workshops.thoughtbot.com/sections/10 "Boston Rails
Antipatterns") and [San Francisco](http://workshops.thoughtbot.com/sections/12
"Rails AntiPatterns (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 <abbr
title="Single responsibility, Open-closed, Liskov substitution, Interface
segregation and Dependency inversion">SOLID</abbr> 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.

* [Clean
  Code](http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)
* This is the post that introduced the grouping of concepts behind <abbr
  title="Single responsibility, Open-closed, Liskov substitution, Interface
  segregation and Dependency inversion">SOLID</abbr> [The Principles of
  OOD](http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod)
* Here is a video about applying <abbr title="Single responsibility,
  Open-closed, Liskov substitution, Interface segregation and Dependency
  inversion">SOLID</abbr> in Ruby [SOLID Object-Oriented
  Design](http://confreaks.net/videos/240-goruco2009-solid-object-oriented-design)

## 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
<abbr title="Model View Controller">MVC</abbr>, 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](https://thoughtbot.com/blog/post/2831837714/feature-branch-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](https://github.com/rails/rails/commits/master.atom), 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.