Несмотря на то что это принцип достаточно известный и понятный, часто им пренебрегают думая что “в моей ситуации по другому нельзя”, либо просто не понимая последствий этого решения для будущей поддержки проекта.

Небольшая оговорка: рекомендую посмотреть мое выступление с докладом “ментальное программирование” где изложена эта и многие другие концепции.

Разберем конкретный пример. Исходные данные: В проекте есть CRUD для управления пользователями. Задача: вместо удаления делать soft destroy, чтобы иметь возможность восстановить пользователя.

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

В проектах иногда встречаются ссылки, которые строятся без url helpers или содержат логику. Часто по этому поводу либо не заморачиваются, либо пишут обертки где придется и как придется.

А можно поступить так:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

module CustomUrlHelpers
  def register_with_facebook_cpath
    Gateway::Facebook.url_for_callback(register_user_facebook_url)
  end

  def create_link_to_facebook_cpath
    Gateway::Facebook.url_for_callback(create_link_account_facebook_url)
  end

  def edit_company_account_curl(account)
    case account
      when ::Company::CrmAccount
        edit_company_crm_account_url(account)
      when ::Company::GisAccount
        edit_company_gis_account_url(account)
    end
  end

  def facebook_auth_cpath
    '/auth/facebook'
  end
end

В ruby очень распостранены цепочки кода, а еще любовь к “однострочникам”. Только не все йогурты одинаково полезны.

Долго я ничего не писал, но пришло время jekyll). Самое приятное в этом то, что весь текст пишется в виме (как раз сегодня поменял сборку с akitaonrails на janus).

По долгу службы большую часть времени я провожу за анализом кода и прокачиванию разработчиков. И в процессе обнаруживается много разных интересных закономерностей, подходов и антиподходов. Мной уже написано несколько статей на хабре (так же их можно найти на kaize.github.com). В этом блоге я планирую писать небольшие заметки о best practices веб разработки на ruby on rails и смежных технологиях.