Jump to Comments

I am trying to put together a series of articles on “correct” Rails development, for the purpose of helping to get across what I mean to a company that I am working with. I thought I’d post them on my blog because they can be useful for others too.

I see these applying to any size of team, whether it’s a one-man show or a 15-people XP team - although the 15-people team will probably require some additional management processes to function. Those are not, however, key rails development principles.

Here’s the first article. There will likely be more in this series.

DRY - Don’t Repeat Yourself

A key philosophy of Rails is to not repeat your code. Why? Repeated code (aka “wet” code) introduces the potential for bugs, takes longer to write, and is harder to read. If the code needs to change, and it’s repeated in multiple places, then you run the risk of forgetting to update one of the places where it’s been repeated. The result is hard-to-find bugs that take a long time to debug. Other key consequences of repeated code are: it takes longer to write (more things to type), it is more difficult to read (repetition clutters the code), it is more difficult to modify (you never know where to make the change to catch “all” the instances of the thing you want to change).

Keep the code simple and readable

Simple code is easier to read and understand. Therefore, it is easier for multiple people to work with. It is also easier for the original developer to go back to six months later. Finally, it is easier to discover bugs in simple code. Ruby and Rails both provide enormous potential for keeping code clean and simple, even while doing a lot of clever things with it. This is linked to the DRY principle, but subtly different.

MVC with thick models, thin controllers, thin views

Rails provides a full MVC stack, but that doesn’t mean that just writing in Rails will make your application a good MVC application. There are three places to put code in Rails: The model, the view, the controller. The view tells the server how to display the page - nothing more. The view should only ever contain simple display logic. The controller tells the server what functions to call in response to requests. It should only ever contain code that directs the execution towards the correct models and their appropriate method. The model tells the server what the business logic of the application is. Any validations, business logic units, etc, should go into this layer.

Test everything that you write (and only what you write)

Testing is essential for a variety of reasons. First, it provides a safety net to ensure that you don’t break one part of the code when you change another. Secondly, writing tests before writing code forces the developer to think about what they are developing before they start writing code. This always results in better designed, cleaner, more quickly written code. Ideally, the tests should consist of both BDD-type specifications that map directly to the code, and integration tests that check that the application is behaving correctly on the whole.

Tests are of key importance. Any code without an automated test suite is by definition unreliable and resistant to change, since you can have no confidence that changing one thing will not break three others. Testing enables you to be confident that you can make changes without making the code buggy.

Use Rails standard tools/code/plugins wherever possible

One of the advantages of Ruby on Rails is its huge community of developers. They produce many useful plugins which help accelerate development. Moreover, the core Rails distribution includes a large number of utilities (such as validators). These should be used whenever possible, in preference to custom code. Any custom code doing more than pure business logic or simple controller and view logic should be clearly justified.

Continuous unit testing and continuous integration

Tests and specifications should be executed as often as possible. Since the computer does not care how many times it runs the tests, there is no reason to settle for anything less than continuous testing. Tests should be running continuously in the background and notify the developer(s) immediately when they fail. The advantage of this is that developers know immediately when they write a piece of code that causes something else to break. This saves huge amounts of time in debugging.