Обзор книги "Growing Rails Applications in Practice"
В технических книгах я ценю в первую очередь ясность изложения и практическую ценность материала. Такое сочетание, к сожалению, встречается реже чем хотелось бы. С ясностью изложения в книгах в мире Ruby разработки всё более ли менее окей. Но вот уникальные и полезные практические знания найти можно не так часто. Один пример подобной полезной книжки – Confident Ruby, обзор на которую я писал полгода назад. Еще один пример – герой этого дня Growing Rails Applications in Practice, написанная немецкой консалтинговой фирмой книжка объемом всего в 88 страниц.
Авторы, имеющие большой опыт в разработке крупных приложений на рельсах, оформили свои методы написания приложений в произведение, на чтение которого уйдет максимум два часа. В чем же заключаются эти методы?
Голые рельсы
Авторы не предлагают никаких волшебных гемов и запутанных паттернов проектирования. Вместо этого они сконцентрировались на эффективном использовании тех инструментов, которые уже предоставляют Rails.
Стройные контроллеры
Да-да, идея о thin controllers, fat models не нова. Однако в книжке приведён конкретный паттерн написания стройных контроллеров, а так же несколько техник и фишек, упрощающих их расширение и предотвращающих их утолщение. Например, рекомендуется добавить private метод #{имя_модели}_scope, и проводить поиск по записям при помощи этого метода:
private
def course_scope
Course.scoped
end
def build_course
@course ||= course_scope
@course.attributes = course_params
end
Теперь мы можем легко добавить ограничения доступа к различным записям, редактируя только один метод course_scope, во всех остальных местах код менять не придётся:
def course_scope
current_user.admin? ? Course.scoped : current_user.courses
end
Да, не самая новая техника, но авторы собрали несколько вот таких вот очевидных и нужных вещей в одну идею о том, как надо писать контроллеры. Ещё интересно, что в книге не сильно жалуют before_action, предпочитая вызывать методы напрямую. Поначалу мне казалось это глупостью, но немного поразмыслив я понял, что в этом и правда есть смысл: труднее запутаться в коде, легче редактировать отдельные методы.
Особой строкой идёт нелюбовь авторов книги к гемам вроде Interited Recourses. Я сам терпеть не могу такие библиотеки, которые якобы упрощают написание контроллеров, но на самом деле лишь добавляют лишний уровень сложности.
Сервисные объекты
Очень понравился подход авторов к сервисным объектам. Парни предлагают разбивать контроллеры не только по моделям, но и по различным сервисным объектам. Допустим, у вас есть TransactionsController, внутри которого, в том числе, есть код для проведения переводов из одного счёта в другой:
def transfer
source_account = Account.find(params[:source_id])
amount = params[:amount]
if (source_account.summary - amount) > 0
transaction = Transaction.new(amount: amount, source_account_id: source_account.id, target_account_id: params[:target_id])
if transaction.save!
head :ok
else
render json: { erros: transaction.errors }
end
else
render json: { erros: “Source account doesn’t have enough money to make this transfer” }
end
end
И вот этот большой (относительно) метод валяется в TransactionsController, увеличивая размер этого контроллера на порядок и делая его далеко не стройным и не красивым. Решением такой проблемы будет добавить TransfersController который будет использовать сервисный объект Transfer. Этот сервисный объект использует ActiveModel для валидаций.
class TransfersController < ApplicationController
def create
build_transfer
if @transfer.create
head :ok
else
render json: { errors: @transfer.errors }
end
end
private
def build_transfer
@transfer = Transfer.new(transfer_params)
end
def transfer_params
params.require(:sign_in).permit(:source_id, :target_id, :amount)
end
end
class Transfer
include ActiveModel::Model
include ActiveSupport::Callbacks
include ActiveModel::Validations::Callbacks
attribute :source_id, :integer
attribute :target_id, :integer
attribute :amount, :integer
validate :validate_source_account_balance
define_callbacks :create
after_create :create_transaction
def save
if valid?
run_callbacks :create do
true
end
else
false
end
end
def source_account
Account.find(source_id)
end
private
def create_transaction
Transaction.create(source_account_id: source_id, target_account_id: target_id, amount: amount)
end
def validate_source_account_balance
if source_account.balance < amount
errors.add(:amount, “Requested amount is not present in source account”)
end
end
end
Тут вы скажете, что кода в итоге получилось в 4 раза больше, чем в изначальном варианте. Но это только потому, что в модели Transfer много boilerplate кода, который должен быть вынесен в класс, от которого будут наследоваться все подобные сервисные объекты. В книге предлагают использовать гем ActiveType, который является надстройкой над ActiveModel с несколькими дополнительным фичами сверху.
После изменений мы получаем небольшой новый контроллер и лёгкую для восприятия модель, которые легко расширить для различных видов переводов в будущем. Например, мы можем добавить оповещение по почте в after_save коллбэке этой новой модели.
Признаю, написанный мной пример не идеален. Например, мне лично не нравится, что Transfer в данном случае прячет в себе код для создания транзакции. Ещё я не добавил вывода сообщений об ошибках при сохранении транзакции. Тем не менее, техника, предлагаемая авторами Growing Rails Applications in Practice, заслуживает внимания. Сам я ещё не имел удовольствия активно её применить, но описанная методика мне определённо нравится своей простотой и элегантностью. Как минимум читаемость кода повышается в разы. В самой книге гораздо больше примеров гораздо больших размеров.
Недостатки книги
Во-первых, четверть книги посвящена организации CSS, и эта часть является пересказом системы BEM. Я сам лично больше люблю SMACSS. Но дело даже не в этом – в книге про рост рельсовых приложений я не ожидал такого количества текста про написание фронтенда. Возможно, сказывается тот факт, что я в целом уже года 3-4 как устал от CSS и мне про него утомительно слушать в целом.
Во-вторых, ребята советуют использовать Cucumber. Не буду долго распинаться, но скажу, что считаю Cucumber потрясающе идиотской штукой, которую никому не советую использовать.
В-третьих, сама техника написания контроллеров не так хороша, как её описывают авторы книги. Я попробовал (и продолжу эксперименты в этом направлении) следовать их рекомендациям в коде mkdev. Читаемость кода и правда улучшилась, вот, например, метод обновления курса:
def update
load_course
build_course
save_course or render :edit
end
Проблемы начались когда я попробовал использовать ту же технику для модели Task, которая belongs_to :course. Следуя советам из Growing Rails Applications у меня получился такой набор private-методов:
def load_course
@course = course_scope.find(params[:course_id])
end
def course_scope
Course.where(nil)
end
def load_task
@task = task_scope.find(params[:id])
end
def build_task
@task ||= task_scope.build
@task.attributes = task_params
end
def save_task
if @task.save
redirect_to admin_course_tasks_path(@course)
end
end
def task_scope
load_course
@course.tasks
end
def task_params
task_params = params.fetch(:task, {})
task_params.permit(:title, :text, :position)
end
Это уже 7 методов для простого CRUD, не считая ещё 7 стандартных (index, create, update и т.п.). Переменые @course и @task размазаны по этим методам. Создаётся ощущение, что стоит добавить ещё чуть-чуть кода и получится запутанная мешанина. Не уверен, что такой вариант мне нравится больше привычного.
Итого
Growing Rails Applications in Practice – очень клёвая книга, которая стоит своих денег. Я привёл лишь два микроскопических примера из множества техник, описанных в таком небольшим произведении. Абсолютно никакой воды, практически ничего лишнего и точно пригодится как новичкам, не знающим как организовать свой код, так и профи, постоянно ищущим способы улучшить свой код. Методы авторов далеко не идеальны и к их советам, естественно, нужно относиться критически, брать лучшее и откидывать очевидно стрёмное.
Уже прочитавшие, что думаете о книжке?