Introduction

Ruby on Rails is more than 15 years old and its community has developed a number of principles for building applications that are fast, fun and easy to change: Don’t repeat yourself, keep logic out of your views, don’t overload your controllers, and keep business logic in your models. These principles carry most applications to their first release or beyond.

However, these principles only get you so far. After a few releases, most applications begin to suffer. Models become overloaded, classes become few and large, tests become slow, and changes become painful. In many applications, there comes a day when the developers realize that there’s no going back; the application is a twisted mess and the only way out is a rewrite or a new job.

Fortunately, it doesn’t have to be this way. Developers have been using object-oriented programming for several decades and there’s a wealth of knowledge out there that still applies to developing applications today. We can use the lessons learned by these developers to write good Rails applications by applying good object-oriented programming.

Ruby Science outlines a process for detecting emerging problems in code and dives into the solutions, old and new.