В корпоративных проектах Java / .Net каждый разработчик имеет все зависимости в своем пути к классам?

Question

В крупномасштабных проектах Java / .Net Enterprise, каждому разработчику нужно все компонентов / библиотек / зависимостей в их classpath / локальной среде разработки для заставить его строить?

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

---

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

Крупные корпоративные проекты обычно организованы первым или вторым способом?

---

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

Другая организация - если вы динамически загружаете используемые классы, вы можете создавать их, не имея ни одного из них в своем пути к классам. Чтобы запустить его, вашему classpath нужен только доступ к тем, которые вы фактически загружаете (может быть много других, которые образуют разные части проекта, которые вы не загружаете).

Это теоретические возможности; но какова стандартная практика для корпоративных проектов, в ... ну, на практике?

---

Я расширил это, чтобы включить .Net, потому что я думаю, что там возникнут те же проблемы (DLL ад?)

Answer 1

Есть разные ответы на этот вопрос для каждого проекта. Несколько общих моментов:

• «запуск подмножества приложения» часто невозможно, так как очень немногие приложения являются достаточно модульными, чтобы каждая их часть могла работать независимо.
• Иногда у вас есть ядро ​​приложения, которое всегда требуется, и модули, построенные на этом ядре, которые более или менее независимы друг от друга.
• Большая разница, как правило, заключается не в том, чтобы иметь или не иметь все компоненты, а в том, чтобы иметь их в качестве исходного кода, или в том, чтобы они были в виде файлов JAR.
• В больших приложениях разработчики обычно имеют только части, над которыми они работают, в исходном коде, а остальные - в виде файлов JAR
• Если вам нужна модульность во время выполнения (т. Е. Компоненты загружаются и выгружаются по требованию во время выполнения), это то, для чего предназначен OSGi .

Answer 2

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

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

Answer 3

Я, конечно, согласен с комментариями, что было бы "хорошо" отделить вещи. Но на практике это очень редко.

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

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

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

Answer 4

Хорошая структура проекта сломает вещи, чтобы вы могли запускать независимые модули.

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

Если вы правильно используете хорошую инфраструктуру управления зависимостями, такую ​​как Maven или Ivy, вы можете хранить скомпилированные модули на сервере и загружать эти зависимости по мере необходимости.

Вы также можете избежать множества фиктивных объектов и сервисов, которые помогут сломать зависимости тестирования от других компонентов продукта.

Answer 5

На мой взгляд, дело не в том, могут ли разработчики работать над подмножеством приложения, а в том, чтобы управлять зависимостями между проектами (например, проектами Eclipse), которые составляют приложение. Часто у вас может быть дерево таких проектов, где один или несколько проектов могут зависеть от других проектов. В таких случаях обычно роль проекта upstream / common заключается в том, чтобы убедиться, что проекты downstream не нарушены из-за изменений в этом проекте upstream.

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

    utils
   /     \
proja   projb

В этом случае лицо, работающее по utils , должно также иметь proja и projb на своих среда разработки, так как любое изменение в utils сломает их. Однако, если вы работаете только с projb, вам, возможно, не придется включать proja, поскольку вы не зависите от этого проекта.

Answer 6

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

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

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

Если вы имеете в виду тестовые случаи как нечто отдельное, они обычно не упакованы с рабочим кодом.