Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Правила для разработчиков от Sandi Metz

Anna | 20.06.2014 | нет комментариев

В январе этого года, Sandi Metz представила свои правила для разработчиков в эфире подкаста Ruby Rogues. Приблизительно в это же время, я и моя команда начали новейший план. Эта статья описывает тот навык, что мы получили, применяя эти правила к своему новому плану.

Правила

  1. Классы не могут содержать огромнее чем 100 строк кода.
  2. Способы не могут быть длиннее чем 5 строк кода.
  3. Невозможно передавать огромнее 4 параметров в способ. Значения хэша также считаются параметрами.
  4. Контроллеры могут инстанциировать только один объект. Следственно, представление может знать только об одной инстанс переменной и должно только слать сообщения этому объекту (@object.collaborator.value не возможен).

Когда следует нарушать правила

Перефразируя Sandi, “Вы можете нарушить правила, только если у вас есть на то важные поводы, либо ваш компаньон по программированию это одобряет”. Вам следует получить разрешение от вашего компаньона по программированию либо человека, тот, что ревьюет ваш код.

Пускай это будет непоколебимым правилом номер 0.

100-строковые классы

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

Это относится и к спекам. Был случай когда мы обнаружили файл спека превыщающий данный лимит. Он помог нам понять, что мы тестируем слишком много фич. Было принято решение разбить данный файл на несколько, больше сфокусированых на фичах, спеков.

Мы пришли к итогу, что git diff вовсе не непременно показывает нам, когда мы превысили лимит в 100 строк.

5 строк кода на способ

Лимитация способа пятью строками пожайлуй самое увлекательное правило.
Мы договорились на том, что ‘if’, ‘else’, ‘end’ тоже считаются. В блоке ‘if’ с двумя ответвлениями, всякое ответвление должно умещаться в одну строку.

Скажем:

def validate_actor
  if actor_type == 'Group'
    user_must_belong_to_group
  elsif actor_type == 'User'
    user_must_be_the_same_as_actor
  end
end

5 строк гарантируют, что мы никогда не будем применять ‘else’ с ‘elsif’.

Лимитация в одну строку на ответвление всподвигло нас применять приватные способы с отлично продуманными именами для достижения желаемого итога. Приватные способы — чудесная документация. Они нуждаются в дюже внятных именах, что принудило нас задуматься о том, какой код должен быть выделен.

Mаксимум 4 довода на способ

Использование данного правила в Rails стало для нас огромным испытанием, исключительно в представлениях.

Хелперы представления, такие как ‘link_to’ либо ‘form_for’, могут затребовать много параметров для правильной работы. Мы безусловно прилагали усилия для ограничения числа передаваемых доводов, но порой возвращались к правилу 0 и оставляли их, если не находили лучшего метода.

Инстанциировать максимум один объект в контроллере

Это правило поразило нас огромнее каждого, раньше чем мы приступили к новому плану. Нередко нам требовалось огромнее одного типа объекта на странице. Скажем, на домашней странице нам необходимы были лента активности и счетчик уведомлений.

Мы решили эту загвоздку через образец проектирования Фасад. А выглядело это так:

app/facades/dashboard.rb:

class Dashboard
  def initialize(user)
    @user = user
  end

  def new_status
    @new_status ||= Status.new
  end

  def statuses
    Status.for(user)
  end

  def notifications
    @notifications ||= user.notifications
  end

  private

  attr_reader :user
end

app/controllers/dashboards_controller.rb:

class DashboardsController < ApplicationController
  before_filter :authorize

  def show
    @dashboard = Dashboard.new(current_user)
  end
end

app/views/dashboards/show.html.erb:

<%= render 'profile' %>
<%= render 'groups', groups: @dashboard.group %>

<%= render 'statuses/form', status: @dashboard.new_status %>
<%= render 'statuses', statuses: @dashboard.statuses %>

Класс ‘Dashboard’ предоставляет всеобщий интерфейс для размещения взаимодействующих объектов пользователя, и теснее его объект мы передаем в образцы представления.

Мы договорились, что мемоизации переменных в контроллере не влияют на это лимитация. И пришли к соглашению прибавлять префикс в виде нижнего подчеркивания к неиспользуемым переменным, Дабы отразить тот факт, что они предуготовлены для применения в образце:

def calculate
  @_result_of_expensive_calculation ||= SuperCalculator.get_started(thing)
end

Невиданый триумф!

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

 

Источник: programmingmaster.ru

 

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB