paint-brush
A Refactoring Guide for Ruby on Railsby@muriloRoque
242 reads

A Refactoring Guide for Ruby on Rails

by MuriloRoqueJune 21st, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

In this article, I’m gonna walk you through some steps to make your Ruby on Rails code more beautiful and readable. You should understand what a basic MVC is before going forward, take a look at this article. Read and apply each of the steps in order, I will start with some messy code in the View and split it through the whole MVC until I get to the Model. This is the heart of our MVC, where we should put the most complex code logic and transfer (almost) everything to our controllers.
featured image - A Refactoring Guide for Ruby on Rails
MuriloRoque HackerNoon profile picture

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live” — John F. Woods

The above quote is very intriguing and it makes us programmers think twice before writing a piece of code. I first saw this when I was at the beginning of my course at Microverse, and it changed everything for me, I was always thinking about how to write better functions and use the best linters.

In this article, I’m gonna walk you through some steps to make your Ruby on Rails code more beautiful and readable. You should understand what a basic MVC is before going forward, take a look at this article. Read and apply each of the steps in order, I will start with some messy code in the View and split it through the whole MVC until I get to the Model.

Example Project

Let’s say we have a model named User that has a column name and a column named age, which is an integer. We want to list all the users that are older than 16, so we know who’s able to get a driver’s license.

1 — Views

Main Views

Here’s a representation of our initial View:

Of course, this solves our problem and will yield the desired results, BUT it would never pass a code review. Just imagine a problem 10 times bigger than ours and you will understand why.

For the next step, we are transferring this code to a partial view, which will isolate our code from the main view.

Partials

After transferring our code to a partial, our main view would then render it and the partial would have the previous main view code. This change is a little better, BUT it’s still not good enough because we have an Active Record Query in our View, which is the worst possible scenario. Check it out:

Helpers

Using a helper is a big step from the views since it allows you to separate your HTML code from Ruby's logic. Check it out:

Isn’t it nice? It looks a lot more organized for me, and also for your code reviewer. But it is not perfect, we didn’t get rid of that query in our View yet.

2— Controllers

Wait a minute, aren’t we using an MVC? Then we should make use of it and transfer our code safely to our controllers, here’s how we do it:

Right now that psychopath is a little calmer, but he isn’t happy yet, we need to make sure he won’t harm us, so let’s continue.

3 — Models

Ah, the Models! This is the heart of our MVC, where we should put the most complex code logic and transfer (almost) everything to. From our example, the most important thing we need to transfer here is that Query, which is currently in our controller. For that, we are going to use a scope:

Here you go, now you can sleep peacefully.

I hope you could get the main idea behind refactoring a Rails code, you can just simply follow these lines: Fat Models, Skinny Controllers, and Dumb Views.

If you liked this article, make sure to:

- Check out my GitHub profile