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
Ruby Science outlines a process for detecting emerging problems in
code and dives into the solutions, old and new.
The canonical reference for writing fantastic Rails applications from authors who have created hundreds.