Как вы читаете существующий проект Rails?

Question

Когда вы начинаете работать над существующим проектом Rails, какие шаги вы предпринимаете, чтобы понять код? С чего начать? Что вы используете, чтобы получить представление высокого уровня, прежде чем углубляться в контроллеры, модели, помощники и представления? У вас есть какие-то конкретные приемы, приемы или инструменты, которые помогают ускорить процесс?

Пожалуйста, не отвечайте "Learn Rails & Ruby" (как один из ответов последний парень , который спросил это, получил - он также не получил много ответа на свой вопрос, поэтому я подумал, что я попросил бы еще раз и подсказать чуть больше). Мне довольно удобно с моим собственным кодом. Это сортировка других людей, которая заставляет меня задуматься и долго грохочет.

Answer 1

Посмотрите на модели. Если приложение написано хорошо, это должно дать вам представление о его доменной модели, в которой должна жить интересная логика. Я также смотрю на тесты для моделей.

Способ реализации контроллеров / представлений должен быть очевидным только при использовании приложения Rails и отслеживании URL-адресов.

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

Answer 2

Сначала я использую приложение, отмечая интересные названия контроллера и действия.

Затем я начинаю читать код для этих контроллеров и для соответствующих моделей, когда это необходимо. Представления обычно менее важны.

Answer 3

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

1) Я думаю, что первое, что нужно сделать, это понять, что, черт возьми, приложение на самом деле делает. Используйте его, по крайней мере, достаточно долго, чтобы составить представление о том, каково его основное назначение и какими могут быть различные типы данных и какие действия вы можете выполнять, и что наиболее важно, почему .

2) Вам нужно сделать шаг назад и увидеть большую картину. Я думаю, что лучший способ сделать это - начать с schema.rb. Это говорит вам о нескольких действительно важных вещах:

• Что такое словарь / понятия этого проекта. Что на самом деле означает «пользователь» в этом приложении? Почему в приложении есть модели «Пользователь» и «Учетная запись» и как они отличаются / связаны?
• Вы можете узнать, какие есть модели, посмотрев в app/models, но это фактически скажет вам, какие данные содержит каждая модель.
• Благодаря полям *_id вы узнаете ассоциации между моделями, что поможет вам понять, как все это сочетается.

Я бы проследил за этим, посмотрев в файле *.rb каждой модели (надеюсь) комментарии, проверки, ассоциации и любую дополнительную логику, относящуюся к каждой. Следите за регулярными старыми классами Ruby, которые могут жить в lib/.

3) Лично я бы кратко взглянул на routes.rb, поскольку он расскажет вам две ключевые вещи: краткий обзор всех действий в приложении и, если маршруты и контроллеры / действия хорошо названный и продуманный, быстрое понимание того, где могут жить различные функции.

---

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

Не забудьте использовать остальные инструменты: отладчики Ruby / Rails, инструменты разработки браузера, логи и т. Д.

Answer 4

Запустите тесты. : -)

Если вам повезет, он будет построен на RSpec, и это будет описывать поведение независимо от реализации.

Answer 5

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

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

Когда мне нужно изменить или расширить существующий код, я должен иметь четкое представление о том, каким будет первое изменение - если нет, то мне, вероятно, пока не стоит дурачиться с кодом! В приложении на Rails изменение, скорее всего, затронет вид, модель или их комбинацию, и я должен быть в состоянии довольно быстро идентифицировать соответствующие элементы. Если есть тесты, я проверяю, что они выполняются, затем пытаюсь написать тест, который показывает недостающие функциональные возможности, и мы уходим. Если тестов нет, то это немного сложнее - я буду беспокоиться о том, что могу случайно что-то сломать: я бы подумал о добавлении тестов, чтобы придать себе больше уверенности, что, в свою очередь, начнет формировать некоторое понимание области под изучение. Я должен довольно быстро войти в цикл красно-зеленый-рефактор , набирая скорость, пока я изучаю свой путь.

Answer 6

Если проект Rails находится в несколько стабильном состоянии, то я всегда был большим поклонником использования отладчика для навигации по базе кода. Я включу браузер и начну взаимодействовать с приложением, затем нацеливаюсь на какую-то часть функций и установлю точку останова в начале связанной функции. Имея это в виду, я просто изучаю параметры, входящие в функцию, и возвращаемое значение, чтобы лучше понять, что происходит. Как только вы освоитесь, вы можете немного изменить функциональность, чтобы понять, что происходит. Просто выполнить некоторый статический анализ кода может быть громоздким! Удачи!

Answer 7

Я бы сказал, посмотрите на тесты (или спецификации, если проект использует RSpec), чтобы получить представление о том, что должно делать приложение. Как только вы поймете на верхнем уровне, как должны вести себя модели / представления / контроллеры, вы можете углубиться в реализации.

Answer 8

Помимо уже опубликованных советов по запуску спецификаций и декомпозиции MVC, мне также нравится:

rake routes

как еще один способ получить общее представление обо всех маршрутах в приложении

./script/console

Консоль rails irb по-прежнему мой любимый способ проверки моделей и методов моделей. Соберите несколько записей и работайте с ними в irb. Я знаю, что это помогает мне во время разработки и тестирования.

Answer 9

1. Я запускаю rake test в терминале
2. Если среда не загружается, я просматриваю трассировку стека, чтобы выяснить, что происходит, а затем исправляю ее, чтобы среда загружалась и снова запускала тесты
3. Я загружаю сервер и открываю приложение в браузере. Щелкать вокруг.
4. Начните работать с поставленными задачами.
5. Если код рулит, я счастлив. Если код отстой, я причиню ему боль ради удовольствия .

Answer 10

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