🎯 О чём этот конспект: Подробный разбор архитектуры, процесса сборки и кастомизации GigaIDE — российской среды разработки от Сбера. В видео Владимир Ярославский (разработчик GigaIDE) объясняет, как на базе IntelliJ Community Edition создать полноценную Enterprise-платформу с поддержкой Spring, SQL и AI-ассистента.

👤 Кому будет полезно: Вайбкодерам, Java-разработчикам, системным инженерам и всем, кто ищет замену продуктам JetBrains в условиях ограничений.

✨ Что получите: Пошаговый алгоритм сборки собственной IDE из исходников, понимание структуры плагинов IntelliJ и методику реализации поддержки кастомных языков через BNF-грамматики.

1. Архитектура GigaIDE: От Open Source к Enterprise

Контекст: После ухода JetBrains с российского рынка возникла необходимость в суверенной IDE, поддерживающей актуальные версии JDK (21+) и фреймворков. Команда Сбера выбрала путь создания форка на базе IntelliJ IDEA Community Edition (лицензия Apache 2.0). Продукт разделен на два направления: Cloud-версия (на базе VS Code) и Desktop-версия (на базе IntelliJ). Десктопная GigaIDE — это ядро Community + 70 отобранных плагинов + собственные закрытые разработки для поддержки Spring и баз данных.

Выгода: Полная независимость от обновлений JetBrains, наличие встроенного AI-ассистента GigaCode и поддержка специфических Enterprise-инструментов «из коробки».

Как применить:

• Шаг 1: Выбор базы — Используйте IntelliJ IDEA Community Edition как фундамент. Она содержит мощный редактор, поддержку систем контроля версий и базовую Java-инфраструктуру.
• Шаг 2: Лицензионный аудит — Ознакомьтесь с Apache 2.0. Она позволяет модифицировать код и использовать его в коммерческих целях без открытия исходников ваших надстроек.
• Шаг 3: Разделение версий — Разделите продукт на Community (бесплатная база) и Ultimate/Professional (платные модули: Spring, SQL, Docker).

Результат: Масштабируемая платформа, которую можно развивать независимо от вендора.

2. Пошаговый алгоритм сборки IDE из исходников

Контекст: Чтобы кастомизировать IDE (менять Splash-screen, названия, предустановленные настройки), нельзя просто взять бинарник. Нужно собирать проект целиком. Процесс требует специфической настройки окружения и учета нюансов зависимостей Android-проекта, который вшит в исходники IntelliJ.

Выгода: Возможность создавать брендированные сборки IDE с предустановленным набором инструментов для всей команды.

Как применить:

• Шаг 1: Подготовка окружения — Скачайте исходники IntelliJ Community с GitHub. Установите два обязательных плагина: IntelliJ IDEA Project Structure и Grammar-Kit.
• Шаг 2: Настройка зависимостей — Добавьте библиотеку Service Messages в локальный репозиторий Maven. Скачайте специальную JetBrains Runtime (JBR) для сборки.
• Шаг 3: Конфигурация сборки — Запустите конфигурацию через Gradle. Будьте готовы к скачиванию дополнительных 640 МБ зависимостей для Android-модулей.
• Шаг 4: Компиляция — Запустите процесс сборки. На мощном ПК это занимает около 1 часа.

# Пример команды для сборки плагина внутри проекта
./gradlew buildPlugin

Результат: Готовый дистрибутив IDE в папке out, готовый к установке на ОС (Windows, Linux, macOS).

3. Реализация поддержки SQL и кастомных языков через BNF

Контекст: Одной из самых сложных задач была замена Database Navigator из Ultimate-версии. Разработчики использовали BNF (Backus-Naur Form) для описания грамматики SQL. Основная проблема — BNF написан «для людей», а генератору кода (Grammar-Kit) нужны строгие правила без левой рекурсии и с оптимизированными предиктами.

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

Как применить:

• Шаг 1: Описание грамматики — Создайте файл .bnf с правилами языка. Для SQL это около 2500 правил.
• Шаг 2: Оптимизация предиктов — Выносите общие множители за скобки. Если несколько правил начинаются одинаково (например, row_value_predicate), создайте общее стартовое правило, чтобы парсер не перебирал варианты по 10 раз.
• Шаг 3: Генерация парсера — Используйте Grammar-Kit для генерации Java-кода парсера и лексера.
• Шаг 4: Регистрация в платформе — Опишите ParserDefinition в plugin.xml.

<extensions defaultExtensionNs="com.intellij">
  <fileType name="MySQL" implementationClass="com.sber.ide.sql.MySqlFileType" fieldName="INSTANCE" extensions="mysql"/>
  <lang.parserDefinition language="MySQL" implementationClass="com.sber.ide.sql.MySqlParserDefinition"/>
</extensions>

Результат: Полноценная поддержка языка с PSI-деревом (Program Structure Interface), позволяющая делать глубокий анализ кода.

4. Лайфхаки по разработке и отладке плагинов

Контекст: При сборке GigaIDE команда столкнулась с тем, что многие Open Source плагины заброшены и несовместимы с новыми версиями API IntelliJ. Также возникали критические ошибки компилятора (StackOverflowError) при обработке гигантских сгенерированных классов парсера.

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

Как применить:

• Лайфхак 1: Изоляция ID — Дайте сторонним плагинам собственные уникальные ID в вашей сборке. Это предотвратит попытки IDE обновиться из официального маркетплейса на несовместимые версии.
• Лайфхак 2: Борьба с StackOverflow в компиляторе — Если сгенерированный парсер слишком велик, используйте ключевое слово private в BNF для промежуточных правил. Это уменьшит количество генерируемых PSI-классов и ускорит сборку в 2 раза.
• Лайфхак 3: Профили плагинов — Реализуйте механизм включения групп плагинов «одной кнопкой» (например, профиль «Тестировщик», «Backend», «Frontend»), чтобы не перегружать память.
• Лайфхак 4: Отладка парсера — Используйте View PSI Structure в меню Tools (нужно включить внутренний режим IDE), чтобы видеть, как дерево разложило ваш код в реальном времени.

Результат: Стабильная работа IDE даже с сотней установленных плагинов.

FAQ

В: Чем GigaIDE отличается от обычной IntelliJ IDEA Community?

О: GigaIDE включает в себя предустановленный AI-ассистент GigaCode, поддержку Spring (которой нет в Community), расширенные инструменты для работы с SQL и базами данных, а также более 70 проверенных на уязвимости плагинов для DevOps и тестирования.

В: Можно ли использовать GigaIDE для фронтенд-разработки (JS/TS)?

О: На текущий момент (версия Community/Backend) фокус сделан на Java/Kotlin. Однако поддержка Fullstack (JS, TS, Python) активно разрабатывается и ожидается в версии Fullstack к концу 2024 года.

В: Безопасно ли использовать GigaIDE в закрытом контуре компании?

О: Да, GigaIDE включена в реестр российского ПО. Внутри банковского контура используются дополнительные плагины для мониторинга ошибок и управления доступом, но внешняя версия не собирает пользовательский код. Большая часть кода базируется на открытом Open Source.

В: Как бороться с тормозами, если в IDE установлено слишком много плагинов?

О: В GigaIDE реализована система профилей. Вы можете отключить ненужные группы плагинов (например, для автоматизации тестирования, если вы разработчик). Также физическое удаление папок плагинов из директории plugins полностью исключает их влияние на индексацию.

В: Сложно ли перенести свой плагин с IntelliJ на GigaIDE?

О: Практически нет. GigaIDE сохраняет совместимость с API IntelliJ Platform. Основная сложность может возникнуть только при миграции между мажорными версиями платформы (например, с 2023.x на 2024.x), где JetBrains часто меняет внутренние интерфейсы.

Конспект создан на основе видео «История GigaIDE глазами разработчика» канала JPoint. Все права на оригинальный материал принадлежат авторам. Источник: https://www.youtube.com/watch?v=GNvBtOWDrSs