Планы команды IntelliJ Platform на 2020 год

Сегодня мы хотели бы рассказать о некоторых из текущих проектов команды IntelliJ Platform, которые затронут IntelliJ IDEA и другие IDE на базе нашей платформы. Результаты этих проектов будут выпускаться в течение следующего года; некоторые из них попадут уже в релиз 2020.1, который выйдет весной. Проекты, о которых мы хотели бы рассказать, касаются двух больших областей: производительности и поддержки современных сценариев разработки.

Производительность

Скорость индексации

Индексация на данный момент — одно из самых проблемных мест с производительностью наших IDE. Мы планируем подойти к ее решению с нескольких направлений.

Во-первых, мы планируем поддержать готовые фрагменты индекса. Теперь вместо того, чтобы каждая копия IntelliJ IDEA заново индексировала класс java.lang.String, мы сможем предоставить для скачивания готовый фрагмент индекса для JDK, который можно будет переиспользовать без дополнительных затрат CPU. Помимо JDK, мы изучаем возможность предоставлять готовые фрагменты индекса для библиотек из Maven Central, а также для интерпретаторов и пакетов в других IDE. Мы также хотели бы позволять командам и организациям использовать готовые фрагменты индекса для кода своих проектов, но у нас пока нет на этот счет конкретных планов.

Во-вторых, мы планируем сделать индексирование менее мешающим работе, сделав более широкий набор действий доступными во время индексации.

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

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

Новая модель многопоточного доступа к структурам данных IDE

Еще одно проблемное место в производительности — это «замерзание» пользовательского интерфейса. В этом году мы построили инфраструктуру для сбора информации о таких проблемах. Это позволило нам решить многие из них (например, мы создали и задействовали стандартный механизм асинхронной обработки событий от файловой системы). В следующем году мы планируем шагнуть дальше и вынести операции, модифицирующие структуры данных из UI потока.

На заре существования IntelliJ IDEA было принято архитектурное решение, требующее выполнять все модификации структур данных IDE из UI потока. Это включает в себя и базовые действия (вставка символа в документ), и длительные операции (переименование метода, вызываемого из многих мест). Такая архитектура сильно упрощает модель программирования, но очевидным образом ухудшает отзывчивость интерфейса.

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

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

Загрузка и выгрузка плагинов без рестарта

Первые результаты работы в этом направлении попали уже в релиз 2019.3 ^[1], который позволяет устанавливать плагины цветовых тем и клавиатурных раскладок без перезагрузки. В следующей версии мы планируем расширить эту поддержку на все типы плагинов. Мы будем поддерживать загрузку и выгрузку без рестарта для большей части наших собственных плагинов, и мы опубликовали инструкции по поддержке ^[2] для сторонних плагинописателей.

На данном этапе основным преимуществом станет безболезненное обновление плагинов, не требующее перезагрузки. В дальнейшем мы планируем достичь более интересной цели: IDE, которая автоматически загружает только нужный набор плагинов для каждого проекта, который вы в ней открываете. Используете Spring — загружается Spring плагин, нужен Angular — плагин к вашим услугам. Неиспользуемые плагины будут автоматически отключены и не будут расходовать ресурсы и занимать место в интерфейсе.

Поддержка сценариев разработки

Совместное редактирование

Запрос на поддержку совместного редактирования собрал больше всего голосов в нашем issue tracker, и мы рады объявить, что мы работаем над этой функциональностью. В нашем текущем подходе выделяется «главная» IDE, работающая на той машине, где хранится редактируемый исходный код, и «тонкие клиенты», которые могут подключаться к главной IDE и не должны иметь свою копию исходного кода. Каждый из подключенных клиентов имеет свое состояние (набор открытых файлов, позицию каретки, список вариантов автодополнения и т.д.), но при желании может и «следовать» за другим пользователем.

«Тонкие клиенты» будут иметь доступ к базовой функциональности IDE, такой как навигация, автодополнение и отладка, но не будут поддерживать 100% имеющихся функций. (Например, работа с системами контроля версий не входит в текущий план на первоначальный релиз.) Точный набор поддерживаемых функций на данный момент не определен, и мы не готовы отвечать на вопросы про то, что и когда будет поддержано.

Поддержка совместного редактирования основана на протоколе Rider ^[3], поэтому скорее всего она изначально появится в этом продукте и потом распространится на другие IDE. В любом случае, в релизе IntelliJ IDEA 2020.1 ничего из этого не появится — это план на более длительный срок.

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

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

Поддержка запуска в облаке

Уже довольно давно многие наши продукты поддерживают запуск и отладку кода на удаленных компьютерах и в контейнерах. К сожалению, эта поддержка почти везде реализована по-своему, и даже такие универсальные фичи, как поддержка Docker, выглядят в разных IDE по-разному.

Теперь мы добавляем на уровне платформы концепцию «окружения для выполнения», которое дает способ копировать файлы в него или из него, а также запускать в нем процессы. В IntelliJ IDEA 2020.1 мы поддержим выполнение на локальной машине, в Docker-контейнере и через ssh-соединение. Выбирать окружение для выполнения можно будет в конфигурациях запуска для Java и Go.

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

Новый дизайн проектной модели

Проектная модель — это то, как IDE представляет структуру вашего проекта: какие файлы к нему относятся, как они друг от друга зависят, какие библиотеки используются, и т.д. Проектная модель IntelliJ IDEA хорошо нам послужила за прошедшие годы, но мы начали упираться в ее ограничения. Во-первых, она не позволяет произвольным образом смешивать проекты разных типов. Вы можете открыть проект Xcode в AppCode или солюшен Visual Studio в Rider, но нет такой IDE, в которой вы могли бы открыть в одном окне проекты Gradle и Xcode. Во-вторых, она работает на уровне каталогов и не позволяет разным файлам в одном каталоге иметь разные зависимости. Это усложняет интеграцию с билд-системами типа Bazel и создает проблемы в других сценариях.

Новая проектная модель, которую мы называем workspace model, убирает эти ограничения. Она дает и другие преимущества, такие как более быстрое открытие проекта, более гладкая синхронизация с Maven и Gradle, и более удобная модель программирования.

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

Резюме

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

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

Автор: Дмитрий Жемеров

Источник ^[4]