Things you should avoid when you use Ruby on Rails

(Last Updated: 4th Jan 2018)

This list will be updated once I have time. Most of them are applicable to other frameworks, but the examples and solutions are for Ruby/ Rails.

1. N+1 Query

N+1 Query is one of the most common issues in Ruby on Rails. It impacts the system performance pretty much. Sometime it is unavoidable, but most of the time you can eliminate such cases using includes or a gem called goldiloader. To detect such issue in your current system, you should think of using bullet.

2. Functions that are too ruby specific

Ruby has a lot of powerful functions. Examples like sum, strip, replace. They are all expressive and easy to follow even for non-ruby developers.
However, some ‘magic’ functions are not straight forward enough.
Examples like zip, transpose, dig. Using these functions may cause others difficult to follow and thus not recommended.
Remember good programs should be understandable.

3. Overriding Ruby/Rails native implementation

Open Class nature makes ruby so flexible. You can add or even override methods to all classes.
Extending and/or overriding Ruby/Rails native methods (e.g. methods in Array, Hash) should be avoided, however. You may not know how these native classes are used inside Ruby/Rails, nor in fact, no one knows how they will be implemented in the future. It would be very difficult to debug if your implementation conflicts with the native Ruby/Rails.
To make it safe, you should usually create your own classes derived from the native ones, and do the monkey patch on your classes only. Similarly, you should avoid to use gems trying to extend the native functions.

4. Too many instance variables inside controller

Instance variables are convenient. Once declared, it can be used everywhere inside the class. At the same time, you might find it hard to debug.
Normally, you should use instance variables in the following three cases.
- Variables to be displayed in views
- Resource models extracted from parameters that are either the same as the CRUD resource name or its one of its parent models (belongs_to), if any.
- Caching variables inside a specific function that will not be used in anywhere (OO Philosophy: Behaviours rather than attributes)

def popular_post
  @cache_post||=Post.all.popular
end

5. User-defined field names

When user types the Ruby reserved words, your form might throw some exceptions. Examples are tap and class.Of course, for those fields defined by you, you should not use these reserved words as field names.

= simple_form_for @user do |f|
  -f.object.user_defined_fields.each do |udf|
    =f.input udf.to_sym
  =f.button :submit

6. Hack the tools as permanent solution

It is in no doubt can solve your short-term goal by hacking the tools. However, it would harm your system growth in long term. Usually people will have incompatibility issues due to a major version upgrade of system or component. Or you can choose not to upgrade them, of course.
In long term, you should come up with a standard approach to solve your problems. Or do not heavily rely on tools.

7. Guess the use of less frequently used functions

People would guess the use of functions through code segements. Coding is NOT necessarily a guesswork. Do read either RubyDoc and Ruby on Rails API. You would encounter unexpected behaviours if you do not understand how the codes are actually implemented.