10 ошибок в Ruby / Ruby on Rails, которые легко исправить

Ошибками это назвать тяжело. Скорее тонкости использования языка и фреймворка, а их, в зависимости от масштаба проекта, ну очень много может возникнуть…

Есть корректный способ в миграциях менять данные:

#псевдокод
class Migration < BaseMigration
  class User < AR::Base
  end

  def up
    User.update_all smth: 123
  end

  def down
  end
end

Просто объявлем минимальные модели для миграции. Если нужны сложные проеобразования, то лучше написать 1 sql запрос и не использовать activerecord.

Даже если в коде проекта есть модель пользователя, в миграции будет использоваться модель из неймспейса миграции.

По первому пункту могу посоветовать ruby style guide (https://github.com/bbatsov/ruby-style-guide). Там описаны конкретно эти примеры (двойное отрицание, множественные условия в unless и т.д.).
И вообще, на самом деле этот гайд учит писать код не так, чтобы он работал, а чтобы его понимали другие люди, которые потом будут его читать.
А также позволяет уменьшить количество использование лишних блоков кода.

Если вам нужно обрабатывать три различных значения – используйте текстовое поле.

Сомнительный совет, когда есть enum (Rails 4.1+).

Я использую self для пояснения:
self.foo — атрибут
foo — метод

А я люблю unless. Это мой самый любимый момент в Ruby. Я был в восторге от такой возможности, когда только изучал язык.

Private не изменяет видимость методов класса. Многие считают, что метод bar в этом примере будет приватным.

class Foo
  private

  def self.bar
    puts 'bar'
  end
end

Foo.bar # => bar

Если вам нужен приватный метод класса, используйте privat_class_method или singleton class (class << self).

Часто возникает ситуация, когда в методе нужно создать объект, как-то его изменить и возвратить. Очевидной имплементация будет

def agent
  agent = Mechanize.new
  agent.user_agent = 'Mozilla'
  agent
end

С этим кодом все хорошо, но он не очень элегантный. Используя Object#tap можно превратить его в

def agent
  Mechanize.new.tap { |agent| agent.user_agent = 'Mozilla' }
end

Недавно видел куча кода типа

Model.all.present?

не надо так

Model.exists?

Почему-то ничего не было написано про классический User.find, кидающий исключение в случае, если не найдено ни одного юзера и замену ему User.find_by_id

Ну я бы не назвал это прямо ошибками. Скорее некоторый относительно субъективный стайл-гайд.

А вот что касается bang-методов — так вообще уж извините, но это ересь. Вообще плохой пример. Особенно если в проекте используется модульная система и большинство однотипных методов подобного рода вынесены в единый логический модуль — это совет-убийца. Учитывая особенности фреймворка, я бы лучше порекомендовал делать явные проверки, либо (что еще правильнее де-факто) — любой функционал стараться покрывать тестами. Тогда даже если у нас поменяются данные и тест не пройдет — мы узнаем об этом заранее, до того как на реальном проекте какие-то реальные данные вообще хоть куда-то пойдут.

По поводу unless тоже не совсем согласен — приведенный пример не самый удачный. Поправьте меня если неправ, но двойные отрицания лучше всего заменяются на условия, преобразуясь в цепочку условий. В зависимости от ситуации, их можно и обратить, что повысит удобочитаемость. Тот же RubyMine подобные вещи инспектирует и предлагает в некоторых моментах замены как раз подобного рода (не всегда удачно, но у нас по крайней мере есть выбор что удобнее).

А вообще в свое время один умный и опытный товарищ поделился со мной двумя замечательными ссылками:
github.com/arbox/ruby-style-guide
github.com/arbox/rails-style-guide

Советую как минимум, ознакомиться.

> Если мы удалим пользователя, то связанные с ним посты перестанут быть корректными

foreign keys же.

Жадный лоадинг иногда уместно использовать вместе с bullet.