Как модулировать (большое) Java-приложение?

Question

У меня под рукой довольно большое (несколько MLOC) приложение, которое я хотел бы разделить на более удобные в обслуживании отдельные части.В настоящее время продукт состоит примерно из 40 проектов Eclipse, многие из которых имеют взаимозависимости.Одно это делает систему непрерывной сборки неосуществимой, потому что при каждой проверке ее пришлось бы очень сильно перестраивать.

Существует ли "наилучший практический" способ того, как

• определите части, которые могут быть немедленно разделены
• визуально документируйте взаимосвязи
• распутайте существующий код
• обрабатывать "исправления", которые нам нужно применить к библиотекам (в настоящее время обрабатываются путем помещения их в classpath перед фактической библиотекой)

Если есть (бесплатные / открытые) инструменты для поддержки этого, я был бы признателен за подсказки.

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

Редактировать 2009-07-10

Мы находимся в процессе разделения некоторых основных модулей, используя Муравей-Апач/Айви.Действительно полезный и хорошо продуманный инструмент, не навязывающий вам так много, как maven.

Я записал еще несколько общих деталей и личное мнение о том, почему мы это делаем, в своем блоге - слишком длинный, чтобы публиковать его здесь, и, возможно, не всем интересный, поэтому подписывайтесь на свое усмотрение: www.danielschneller.com

Answer 1

Используя OSGi ( ОСГи ) могло бы тебе подойти.Это позволило бы создавать модули из приложения.Вы также можете организовать зависимости лучшим образом.Если вы правильно определили свои интерфейсы между различными модулями, то вы можете использовать непрерывную интеграцию, поскольку вам нужно только перестроить модуль, который вы затронули при регистрации.

Механизмы, предоставляемые OSGi, помогут вам распутать существующий код.Из-за того, как работает загрузка классов, это также помогает вам проще обрабатывать исправления.

Некоторые концепции OSGi, которые кажутся вам подходящими, как показано в Википедии:

Концептуально фреймворк разделен на следующие области:

• Пакеты - Пакеты - это обычные компоненты jar с дополнительными заголовками манифеста.
• Сервисы - Уровень сервисов соединяет пакеты динамическим способом, предлагая модель публикации-поиска-привязки для простых старых объектов Java (POJO).
• Services Registry - API для служб управления (ServiceRegistration, ServiceTracker и ServiceReference).
• Life-Cycle - API для управления жизненным циклом (установка, запуск, остановка, обновление и удаление пакетов).
• Модули - Уровень, который определяет инкапсуляцию и объявление зависимостей (как пакет может импортировать и экспортировать код).
• Безопасность - уровень, который управляет аспектами безопасности, ограничивая функциональность пакета заранее определенными возможностями.

Answer 2

Первый:удачи и хорошего кофе.Вам понадобится и то, и другое.

Однажды у меня была похожая проблема.Устаревший код с ужасными циклическими зависимостями, даже между классами из разных пакетов, таких как org.example.pkg1.A зависит от org.example.pk2.B и наоборот.

Я начал с maven2 и свежих проектов eclipse.Сначала я попытался определить наиболее распространенные функциональные возможности (уровень ведения журнала, общие интерфейсы, общие службы) и создал проекты maven.Каждый раз, когда я был доволен какой-то деталью, я развертывал библиотеку в центральном репозитории nexus, чтобы она почти сразу была доступна для других проектов.

Поэтому я медленно продвигался вверх по слоям.maven2 обрабатывал зависимости, а плагин m2eclipse предоставлял полезное представление зависимостей.Кстати - обычно не так уж сложно преобразовать проект eclipse в проект maven.m2eclipse может сделать это за вас, и вам просто нужно создать несколько новых папок (например, src / main / java) и настроить путь сборки для исходных папок.Это займет всего минуту или две.Но ожидайте больших трудностей, если ваш проект представляет собой плагин eclipse или приложение rcp и вы хотите, чтобы maven не только управлял артефактами, но и создавал и развертывал приложение.

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

Answer 3

У меня был аналогичный опыт работы с небольшой базой кода (40 kloc).Здесь нет никаких "правил".:

• скомпилированный с и без "модуля", чтобы увидеть, как он используется
• Я начал с "конечных модулей", модулей без других зависимостей
• Я обрабатывал циклические зависимости (это очень подверженная ошибкам задача)
• с maven есть много документации (отчетов), которая может быть развернута в вашем процессе CI
• с maven вы всегда можете увидеть, что что использует как на сайте, так и в netbeans (с
  очень хороший ориентированный граф)
• с помощью maven вы можете импортировать библиотечный код в свою кодовую базу, применять исправления исходного кода и компилировать с вашими продуктами (иногда это очень просто, иногда это очень сложно)

Проверьте также Анализатор зависимостей:
_{(источник: javalobby.org)}

Сетевые приложения:

_{(источник: zimmer428.net)}

Answer 4

Переход на Maven для существующей системы болезненный.Однако он может справиться с более чем 100 модульными проектами без особых трудностей.

Answer 5

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

В любом случае вам понадобится работающая система непрерывной интеграции.Ваша первая задача - заставить базу кода создаваться автоматически, чтобы вы могли позволить своей системе CI следить за вашим исходным репозиторием и перестраивать его, когда вы что-то меняете.Здесь я выбрал подход, отличный от Maven, и мы сосредоточились на простой среде Eclipse, поэтому я создал среду сборки, используя файлы ant4eclipse и Team ProjectSet (которые мы используем в любом случае).

Следующим шагом будет избавление от циклических зависимостей - это упростит вашу сборку, избавит от предупреждений Eclipse и в конечном итоге позволит вам перейти к этапу "проверка, скомпилировать один раз, запустить".Это может занять некоторое время:-( Когда вы переносите методы и классы, не перемещайте их, а извлекайте или делегируйте их, оставляя их старые имена где попало и помечая их как устаревшие.Это разделит ваше распутывание с вашим рефакторингом и позволит коду "вне" вашего проекта по-прежнему работать с кодом внутри вашего проекта.

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

Answer 6

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

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

Answer 7

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