Команда Spring АйО продолжает следить за последними новинками в мире инструментов для разработчиков. В нашем новом переводе вы узнаете о недавно появившемся плагине для IntelliJ IDEA, который предоставляет долгожданную многими функциональность.

Лучше поздно, чем никогда! Эта поговорка — возможно, лучший способ описать функциональность, которую мы представим в этой статье, а именно, поддержку рабочих пространств (далее — workspaces — прим. пер.) в IntelliJ IDEA.

Введение

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

Заметка для нетерпеливых: Ниже мы приведем кое-какую теорию и историю, так что если вам не терпится внедрить workspaces в вашу IDE, просто перейдите к главе “Как использовать workspaces” и вперед! Кроме того, присоединитесь к предстоящему вебинару, чтобы узнать больше подробностей. Пожалуйста, заметьте, что этот функционал пока находится в превью, поэтому вы можете столкнуться с багами и ограничениями. 

Тикет на добавление поддержки workspaces болтался в нашем трекере с 2011-го года. Однако, растущая популярность микросервисов и монорепозиториев в середине 2010-х годов, как казалось, сделало концепцию workspaces морально устаревшей. Модель “монорепо” в точности соответствовала фокусу IntelliJ IDEA на подходе “один проект — много модулей”. Тем не менее, потребность в workspaces продолжала расти, что подтверждалось растущим количеством лайков и одобрительных комментариев от пользователей в YouTrack. В следующем разделе мы посмотрим на то, почему workspaces все еще актуальны в 2024-м. 

Почему монорепозитории не положили конец подходу, основанному на workspaces 

Монорепозитории на самом деле имеют множество преимуществ перед другими подходами, такими как мульти-репозитории, а именно:

• Улучшенное взаимодействие. Все разработчики могут видеть, что происходит в других частях проекта, над которым они работают. Каждое изменение становится видимым сразу после коммита кода. Разрабатывая сервис, который коммуницирует с другим сервисом, написанным другой командой, разработчики могут смотреть в код другого сервиса, чтобы понимать, как он работает. 

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

• Межпроектный рефакторинг. Наличие доступа ко всей кодовой базе позволяет IDE индексировать отсылки внутри кода, что означает, что она может обнаруживать изменения и корректно производить рефакторинг. 

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

Если вы выполняете checkout на монорепозитории и открываете его в IntelliJ IDEA, вы увидите, что структура монорепозитория идеально вписывается в парадигму “проект-модули”. Корневой каталог становится “проектом”, а все подкаталоги становятся “модулями”. Поэтому, на этой базе, все выглядело так, как будто модель работала прекрасно, и реализация поддержки workspaces могла быть отложена.

Однако, монорепозитории имеют некоторые недостатки:

• Монорепозитории имеют тенденцию быстро расти. Загрузка массивной кодовой базы и сборка метаданных о коде может потребовать много времени. Большое количество коммитов со всех проектов в пределах монорепозитория может привести к тому, что операции branch, merge и rebase займут больше времени, чем ожидается. 

• Ограничение доступа к подкаталогам может превратиться в серьезный вызов. Например, при использовании Git вы можете делать это, используя submodules или специфическую для определенного провайдера функциональность вроде GitHub’s Codeowners.

• Интеграция с CI/CD также может быть затруднена, если разные проекты в пределах одного монорепозитория имеют разные релизные циклы. 

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

Поэтому, несмотря на множество преимуществ, популярность использования подхода с монорепозиториями стала снижаться по следующим причинам:

• Проблемы с производительностью: Операции clone, pull и merge над кодом стали весьма проблематичны, как только кодовая база начала расти. 

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

• Неизвестные границы: Проекты воспринимаются как одиночный монолит, поэтому код и абстракции могут “утечь” в другие проекты, создавая тесную зависимость. Другим последствием становится “сломанный master”. Если всего лишь один проект в монорепозитории оказывается сломан, система воспринимает весь монорепозиторий как сломанный .

• Расфокусировка разработчика: В то время как разработчики обычно работают над отдельными небольшими проектами, в монорепозиториях они вынуждены иметь дело с кодовой базой десятков проектов. 

Все это привело к увеличению числа голосов за тикет IDEA-65293, сделав очевидным тот факт, что нам пора включать workspaces как новую функциональность в наши IDEs. 

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

Workspaces улучшают условия труда разработчиков, когда они работают с несколькими проектами и репозиториями. Заметьте, что workspaces могут быть полезны также и для тех разработчиков, которые предпочитают монорепозитории. Иметь возможность делать checkout для определенных проектов из большого монорепозитория и работать только над ними — большое преимущество.

Если вы хотели бы погрузиться в эту тему глубже, есть несколько подходящих статей, таких как “The issue with monorepos” и “Monorepo is a bad idea”, которые объясняют эти моменты с большим количеством подробностей. 

Что такое workspace?

В одной из дискуссий на форуме поддержки JetBrains кто-то запостил следующее:

Проект: Это по сути описание вашего окончательного ПО продукта.

Workspace не имеет ничего общего с реальными проектами и/или продуктами! Это (в идеале) ваш рабочий стол в IntelliJ IDEA’s, не более чем контейнер для проектов, с которыми вы сейчас работаете. Это текущий срез вашего окружения разработчика. Оно не производит результатов, но контролирует процесс, отвечающий за производство результатов. 

Это лучшее объяснение концепции “workspace”, представленной в этом плагине. Вы можете относиться к workspace как к коллекции проектов, над которыми вы работаете. Каждый проект может использовать свой собственный стек технологий и инструмент сборки и может запускаться независимо.

Пользовательские сценарии для workspaces

Когда делали плагин, мы думали о “типичных” настройках для приложения, включающих:

• Набор бэкенд сервисов.

• API gateway.

• Клиентские приложения, такие как React веб приложение или мобильное приложение.

• Коллекцию кастомизированных библиотек (например, Spring Boot стартеры), используемую всеми сервисами. 

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

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

На основе всего перечисленного выше, мы разработали следующие основные случаи использования и соответствующие им конфигурации workspace для плагина:

1. Fullstack разработчик

Во многих случаях нам надо обновить как фронтенд, так и бэкенд компоненты, которые могут храниться в разных репозиториях. Плагин для workspaces позволяет нам выполнить checkout для проектов из репозиториев независимо друг от друга, добавить их в один workspace и работать с их кодом, как если бы они были в одном проекте. 

2. Разработчик микросервисов

Давайте предположим, что у нас десятки микросервисов в монорепозитории, и нам надо обновить только некоторые из них. Больше нет необходимости импортировать весь репозиторий в IntelliJ IDEA. Мы можем создать workspace и добавить в него только те сервисы, которые нам нужны. Более того, мы также можем использовать разные инструменты сборки для разных проектов. Если вы собираете один сервис с помощью Maven, а другой с помощью Gradle – никаких проблем!

3. Разработчик библиотек

Этот сценарий может использоваться, когда нам нужно обычное “Hello, World!” приложение для теста некоего решения. Идеальным примером для этого является разработка Spring Boot стартера. Тестовое приложение не коммитится в репозиторий кода, но оно может понадобиться нам для упрощения разработки. В этом случае мы можем создать простой проект, запустить приложение, отладить стартер и затем выбросить это приложение или использовать его повторно в другом workspace.

Текущая реализация

Workspace - это отдельный каталог, который хранит ссылки на проекты из других каталогов. Дополнительно, мы можем создать проект внутри каталога workspace, если это необходимо. Workspace не должен вторгаться в настройки сервиса. IntelliJ IDEA хранит настройки сервиса, такие как стиль кода, SDK и т.д., в отдельном файле в каталоге, специфичном для каждого проекта (.idea). Когда мы добавляем проект к workspace, IntelliJ IDEA копирует его настройки в каталог workspace, и затем мы можем поменять их локально. Это означает, что проект может включаться в несколько workspaces с разными настройками. На рисунке внизу показано, как это работает. 

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

Как использовать workspaces

• Установите плагин из JetBrains Marketplace.

• Создайте workspace как новый тип проекта.

• Задайте имя каталога для ваших workspaces и добавьте туда все нужные проекты.

Вы можете запускать проекты по отдельности, используя хорошо известные конфигурации запуска в IDEA или команды от Maven/Gradle. Чтобы запустить несколько проектов одновременно, например, микросервисы, вам наверняка потребуется специальный shell скрипт или Docker compose файл. Мы старались сделать условия работа разработчика настолько знакомыми, насколько можно. 

Ограничения текущей версии

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

• Мы не копируем конфигурации запуска из включенных проектов в workspace. Пока что вам придется создавать конфигурации запуска вручную после импортирования проекта. 

• Также отсутствует постоянная синхронизация настроек. Например, если вы использовали JDK 17 в проекте и затем включили его в workspace – workspace будет использовать JDK 17. Если мы обновляем JDK до более новой версии в “основных” настройках проекта, workspace не “увидит” этого изменения.

• Переименование проектов не поддерживается.

• Разрешение зависимостей на наборе независимых проектов пока в разработке. 

Вы можете найти полный список проблем по ссылке, включенной в YouTrack тикет IDEA-65293. 

Дальнейшие планы

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

• Синхронизация настроек проекта.

• Возможность сохранять и делиться workspace в VCS.

• Поддержка большего числа инструментов сборки.

• Превращение workspace в образцового гражданина во всех IDE.

• Упрощение конфигурации запуска для запуска нескольких проектов сразу.

• Реализация плавного процесса отладки между проектами.

Мы будем рады обратной связи! 

Меня недавно спросили о моей любимой IDE как @java разработчика. У нее был бы легкий код, как у Visual Studio, мульти-проектные возможности, как у @EclipseJavaIDE и все специфичные для Java возможности @intellijidea.

Функциональность поддержки workspaces далека от завершения. Мы только начали над ней работать, и это наш следующий шаг на пути к созданию идеальной IDE. Мы будем рады любой обратной связи, которую вы можете предоставить, поскольку это поможет нам в наших усилиях! Попробуйте новый функционал workspaces и расскажите нам, что вы думаете. Ваши отзывы помогут нам сделать IntelliJ IDEA еще лучше. Вы можете оценить наши усилия на странице плагина или добавить ваши мысли и сообщить о проблемах в YouTrack.

Поставьте нам 5 звезд, если вам понравилась наша инициатива! 

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм - Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.

Ждем всех, присоединяйтесь