Как стать автором
Обновить

5 распространенных ошибок Rails-разработчиков

Время на прочтение 4 мин
Количество просмотров 13K
Автор оригинала: Mike Perham

Я проработал с Rails уже порядочное количество времени, и за это время я видел много Rails-приложений, а также немало прочитал и написал плохого кода на Ruby. И вот вам 5 самых распространенных ошибок, которые я наблюдал практически в каждом приложении.

1. Миграции без ограничений


Ваша модель данных — сердце вашего приложения. Без ограничений схемы, из-за багов в вашем коде, данные будут медленно разрушаться до тех пор, пока вы совсем не сможете положиться ни на одно поле в вашей базе. Вот схема модели Contact:

create_table "contacts" do |t|
  t.integer  "user_id"
  t.string   "name"
  t.string   "phone"
  t.string   "email"
end

Чего тут не хватает? Скорее всего Contact принадлежит (belongs_to) пользователю (User) и у контакта должно быть как минимум имя — используйте ограничения базы данных для этого. Добавив ":null => false" мы всегда будем уверены в целостности модели, даже если в нашем коде валидации будут баги, потому что сама база данных не даст сохранить модель, нарушающую эти ограничения.

create_table "contacts" do |t|
  t.integer  "user_id", :null => false
  t.string   "name", :null => false
  t.string   "phone"
  t.string   "email"
end

Бонус-намек: используйте ":limit => N" для указания разумного размера ваших строковых полей. По умолчанию длина строки устанавливается в 255 символов, и наверное полю «phone» совсем ни к чему такой размер, логично?

2. Объектно-ориентированное программирование


Большинство Rails-разработчиков не пишут объектно-ориентированный Ruby-код. Они пишут MVC-ориентированный код, путем раскладывания моделей и контроллеров по нужным папкам. Некоторые добавляют вспомогательные модули с методами класса в папку «lib», но не более. Это продолжается 2-3 года, прежде чем разработчик осознает: «Rails — это просто Ruby. Я могу создавать простые объекты и компоновать их с фреймворком как угодно, а не как он это предписывает».

Бонус-намек: сделайте фасады для сторонних сервисов, которые вы используете. Создайте фасад-мок для использования в ваших тестах, чтобы не дергать сторонние сервисы во время тестирования.

3. Конкатенация HTML в хелперах


Если вы создаете методы-хелперы (молодцы!), то по крайней мере вы пытаетесь содержать ваши шаблоны в чистоте. Но очень часто разработчики не знают основ создания тегов внутри хелперов, что приводит к мешанине из склеенных строк.

str = "<li class='vehicle_list'> "
str += link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title))
str += " </li>"
str.html_safe

Жесть! Это уродливо и легко ведет к XSS уязвимостям. content_tag — ваш друг!

content_tag :li, :class => 'vehicle_list' do
  link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title))
end

Бонус-намек: начните использовать хелперы, которые принимают в качестве аргумента блок. Вложенные блоки отлично подходят, когда нужно сгенерировать вложенный HTML.

4. Огромные запросы загружают все в память


Вам нужно что-то исправить в данных и вы просто проходите их все в цикле и исправляете, верно?

User.has_purchased(true).each do |customer|
  customer.grant_role(:customer)
end

Теперь представим, что у вас коммерческий сайт и миллион пользователей. Пускай каждый объект класса User занимает в памяти 500 байт. Приведенный ваше код отъест 500 Мб памяти. Вариант получше:

User.has_purchased(true).find_each do |customer|
  customer.grant_role(:customer)
end

find_each использует внутри себя метод find_in_batches, выбирая за раз 1000 записей и существенно снижая потребление памяти.

Бонус-намек: используйте update_all или голый SQL, чтобы выполнять массовые обновления данных. SQL требует некоторого времени для изучения, но преимущества, которые вы получите, будут огромными: до х100 повышения производительности.

5. Ревью кода


Я предполагаю, что вы используете GitHub, а также я предполагаю, что вы не используете пул-реквесты. Если вы тратите день или два для реализации новой фичи, то делайте это в отдельной ветке и используйте пул-реквест. Ваша команда сможет проверить ваш код, подсказать что можно улучшить, а также указать вам на какие-то моменты, которые вы могли упустить из вида. Гарантирую, что это приведет к повышению качества вашего кода.

Бонус-намек: не принимайте пул-реквесты без тестов, которые проходят успешно. Тестирование — бесценно для поддержки вашего приложения в стабильном состоянии и для вашего спокойного сна.



Бонус: полезный комментарий к оригинальной статье

find_each и find_in_batches предпочтительны для больших выборок, однако нужно учитывать, что вы меняете память приложения на циклы процессора для базы данных.

Предположим, что вы делаете запрос, который вернет 1'000'000 записей.

SELECT * FROM users WHERE unindexed_field = true;

Если вы сделаете User.all.each, то база данных сделает один огромный запрос, просчитав весь результат за один раз. Если же вы сделаете User.where(...).find_each(:batch_size => 100), то базе данных придется сделать тот же самый запрос 1'000'000/100 = 10'000 раз. И если вы используете MySQL, то он будет пересчитывать результат каждый раз заново. Т.е. для записей 100-200 он просчитает первые 200 записей, для 200-300 — первые 300 записей, затем для 300-400 — первые 400 записей и так далее до 999900-1000000.

Так что для больших выборок конечно лучше использовать find_each или find_in_batches, но имейте в виду, что это тоже может создать вам проблемы.

Общий «хак» для решения этой задачи такой:

ids = User.where(...).select(:id).all
ids.in_groups_of(100) do |id_group|
  # ...
end
Теги:
Хабы:
+27
Комментарии 23
Комментарии Комментарии 23

Публикации

Истории

Работа

Ruby on Rails
17 вакансий

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн