Enterprise Rails

Chapter 3. Organizing with Modules

Like most projects, the first Rails website I worked on started with just a handful of tables and a handful of classes. In those early days, we couldn’t imagine the features or reports we would need in our third year, which is where we are at the time of this writing. We only knew what we knew about the business at the current moment.

When you just have a handful of tables to deal with, there doesn’t seem to be much reason to impose an organizational strategy. At that time, Rails was at version 0.13, and there weren’t many big Rails sites around whose teams could offer their expert advice on Day One organization either. Such advice can often only be dispensed in hindsight, and back then—and even frequently today—most new Rails users were new to Ruby as well.

So we plodded along, developing our site, and along with it our own 20/20 hindsight. Today, our hindsight is really good, but the organization of our original core application is not so good. As of this writing, the models directory of that core application contains 188 classes.

Such a pile of classes is overwhelming for new employees and even some veterans. It can be quite a challenge to remember where everything is, or what effects a change in one class might have on the other 187 classes. The advice from the original developer of a “big Rails site,” in hindsight, is to organize into modules from Day One.

Even in the initial development of our application, at around class number 40, we sensed ...