The Common Threads Through AntiPatterns

Note: Today’s guest post was originally published on the thoughtbot blog and is republished here with the thumbs up from Chad and thoughtbot.

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 by following techniques that have been around for a long time

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.

• Clean Code
• This is the post that introduced the grouping of concepts behind SOLID The Principles of OOD
• Here is a video about applying SOLID in Ruby 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 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.