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

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

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

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

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

Ответ 8

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

Ответ 9

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

rake routes

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

./script/console

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

Ответ 10

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