Зачем использовать много подпроектов и зависимостей от пакетов

Question

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

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

С Maven или без него - действительно ли такое разделение облегчает жизнь?Разве не компактнее иметь все в одном проекте с четко определенной структурой пакетов для разных слоев?

Answer 1

Распространено делить проекты на API, компоненты реализации, веб-компоненты и т. Д. - когда это необходимо. Крупные проекты - это просто: большие.

Существуют преимущества сохранения отдельных компонентов "

• Повторное использование функциональности (например, веб-слой использует сервисный уровень
• Пакет отдельных компонентов (например, отправить API клиенту)
• Версия подкомпонентов; определить их зависимости от версии

Вы можете делать все то же самое с одним гигантским проектом, но сложнее определить, что и куда идет и почему. Жизнь становится проще, когда эти линии разграничения четко определены.

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

Answer 2

Почему стоит создать отдельный модуль в Maven? Чтобы помочь вам в вашем развитии. Там действительно нет другой причины.

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

1. Разделение задач: да, вы можете сделать это с пакетами, но если он находится в отдельном модуле, он может быть скомпилирован отдельно, и вы можете уменьшить количество путаницы [*] в ваших пакетах.
2. Модули управляются разными командами с собственными циклами выпуска.
3. Более понятный код: если весь ваш даос-код находится в одном модуле, а весь ваш веб-сайт - в другом, вы можете протестировать их отдельно.
4. Модуль может быть отдельным развертываемым объектом. У меня есть проект, который имеет два веб-приложения, 5 пакетов и два других основных модуля (одно ядро ​​для веб-приложения и одно ядро ​​для пакетов). Теперь я могу создавать и развертывать каждый модуль отдельно.
5. Модули опубликованы и используются извне. Если это так, то вам нужно минимальное количество «другого» кода в этом модуле.

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

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

Лично я стараюсь не разделять чрезмерно, если только для этого нет очень веских причин.

[*] Путаница: беспорядок, который описывает связи между пакетами. Пакет A использует B, который использует C, который использует и A, и B. Что-то, что не помогает понять.

Answer 3

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

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

Answer 4

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