Рубиновая структура программы - PullRequest
0 голосов
/ 11 января 2012

Предисловие: Это не так много о том, как структурировать код в файлах. У меня есть это вниз. Это больше тема организации вашего исходного дерева. Надеюсь, кто-то просто скажет: «Вот отличная ссылка на эту тему». Тем не менее, из первых рук мнения по этому вопросу также приветствуются.

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

Java усилила структуру пакета в языке. Слава за это. Затем Eclipse позволяет вам использовать проекты, чтобы иметь (потенциально) независимую - в этом примере мы будем называть их «корзинами» - корзинами связанного кода. Intellij имеет различные, но схожие понятия с «модулями» в единственном экземпляре «проекта». Если вам нужен другой проект, вы, по сути, начинаете с нуля.

Тем не менее, RubyMine не предлагает таких модулей в приложениях ruby, и по умолчанию просто хочет поместить все в корневой каталог. Он позволяет использовать каталоги, поэтому можно просто выбрать произвольную древовидную структуру и работать с ней. Это подразумевает, что их намерение состояло в том, чтобы все классы имели доступ ко всем другим классам в вашем проекте. Это может иметь некоторое разрешение за счет использования Ruby 'модулей', или это может быть просто шаблон системы чести "не ссылаться на это".

Итак, говоря кратко, скажем, что я строил концепции 'foo' и 'bar', и оба зависят от класса 'util'. возможно я разверну их как драгоценные камни, возможно я не буду. Я мог бы:

  • Бросьте их всех в один проект RubyMine и просто игнорируйте тот факт, что у 'foo' и 'bar' нет причин знать друг о друге.
  • Поместите каждый в свой собственный проект RubyMine. Это кажется настоящей болью, если есть параллельное развитие. Прежде всего, «util» должен быть упакован отдельно, а затем включен в качестве внешнего ресурса в другие проекты.

Ни то, ни другое не кажется особенно привлекательным. Thougts

1 Ответ

0 голосов
/ 11 января 2012

Я бы разработал все три независимо, а затем использовал бы самоцвет.В Gemfile для каждого из foo и bar вы можете указать path для драгоценного камня, чтобы вы могли разрабатывать их все одновременно, не беспокоясь о том, чтобы возиться с номерами версий и т. Д.укажите на настоящий драгоценный камень на Rubygems или в каком-нибудь git-хранилище.

Для структур проекта ознакомьтесь с Ruby Packaging Standard и Patterns Gem .

...