Как провести рефакторинг модели Rails, которая содержит значительный объем внутреннего кода?

Question

У меня есть модель Rails 2.X с 421 строк кода / комментариев, которая выполняет значительный объем работы с бэкэндом (открытие HTTP-запросов Get, парсинг RSS, парсинг HTML и т. Д.).В то же время я перехожу в Resque для более быстрого прохождения этого внутреннего кода.Мне интересно, каков будет лучший способ рефакторинга?Должен ли я переместить этот внутренний код в библиотеку, которую я включил в модель?Модуль?Драгоценный камень?

Ваши мысли будут высоко оценены.

У меня в основном есть отдельные основные задачи для каждого элемента данных, который я обрабатываю.то есть парсинг канала RSS, парсинг URL-адреса HTTP, запуск регулярного выражения в этом теле html, а также несколько других задач, и сейчас у меня есть 500 или строки кода в модели;несмотря на то, что большая часть того, что делает модель, вызывается через внутренний скрипт, запускаемый cron

, чтобы сделать его более громоздким и облегчить переход к возврату;я думал о создании отдельных классов для каждой очереди восстановления и использовании там статических методов

Тогда я могу требовать эти классы с помощью серверного сценария 'контроллера', если хотите ... Имеет ли этот подход смысл?

Answer 1

Рассматриваемая модель делает много вещей.

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

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

Answer 2

Ваш лучший выбор с точки зрения тестируемости и мыслительного процесса, вероятно, состоит в том, чтобы разбить эти различные проблемы на их собственные (не ARec) модели. Возможно, у вас есть RssParser, HtmlParser, ServiceRequest и т. Д. В зависимости от вашего первого абзаца.

В зависимости от того, где этот материал используется (несколько проектов?), Возможно, имеет смысл сделать свой собственный гем и обновить его.

Я уже писал большие и маленькие классы Resque, и вы сэкономите много боли, если сделаете классы Resque настолько тонкими, насколько это возможно.

Answer 3

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

Что касается того, как повторно пересмотреть модель, посмотрите весь код модели и задайте себе вопрос: «Что делает эта модель?»Если вы в конечном итоге получаете множество «и» или «или», то вам, вероятно, следует стремиться сделать каждый элемент, разделенный «и» или «или», своим собственным классом (см. http://en.wikipedia.org/wiki/Single_responsibility_principle)..человеку гораздо легче писать тесты, особенно при выполнении внешних HTTP-вызовов API и т. д.