Добрый день! Меня зовут Андрей Слекеничс, я PO GigaIDE, и сегодня мы продолжаем наш экскурс по функциональности GigaIDE.

Первая и предыдущая статьи цикла доступны здесь и здесь. Сегодняшний материал — последний, затрагивающий функциональность GigaIDE Community, и первый, в котором мы переходим к возможностям уже только GigaIDE PRO.

Возможно, вы уже знаете, что IDE семейства IntelliJ IDEA (как и Eclipse) обладают важной особенностью: код, который пользователь видит на экране, в большинстве случаев является результатом рендеринга синтаксического дерева, а не просто текста. Построение этого дерева происходит на этапе открытия проекта, когда появляется сообщение «Indexing…». Наличие полного синтаксического дерева проекта, а также набора его редуцированных форм, достаточных для описания семантики используемых фреймворков, открывает отличные возможности для создания инструментов, улучшающих понимание кода.

Поэтому, начиная разработку GigaIDE, мы сразу запланировали создать базовые инструменты для улучшения понимания кода даже в Community-версии. С одной стороны, мы угадали тренд, с другой — эта функциональность расширила возможности ИИ-помощников, доступных в GigaIDE.

Project: что сделано

Первый инструмент для быстрого понимания проекта, наследованный прямо из Idea Community, — это, конечно, Project — физическая организация файлов и их логическая группировка. Модульность — это то, с чего лично я обычно начинаю анализ любого проекта. Состав, наименование и группировка модулей многое говорят о его функциональности.

Solutions: как сделано

Второй вопрос, который долгое время оставался для меня без ответа, пока я не добрался до используемых библиотек, — это то, какие абстракции и паттерны применялись в реализации. К счастью (или к сожалению), типовые архитектурные решения уже имеют одно или несколько признанных воплощений в виде фреймворков. Поэтому, если вы знакомы с этими фреймворками, вы можете предположить, для чего их подключили. Однако такой анализ занимает время, а если проект содержит от 0,5 млн строк кода, его придётся проводить не один раз.

Поэтому в GigaIDE наряду с окном Project мы реализовали окно Solutions, которое содержит список всех распознанных архитектурных паттернов, реализуемых с помощью того или иного фреймворка. Конечно, на поведение паттернов накладывает отпечаток то, какой фреймворк их реализует, поэтому мы идентифицируем максимально общие сущности.

Подробнее про окно Solutions

Окно Solutions расположено слева. Оно может делить западную часть окна приложения по высоте с другими окнами, такими как Project или Frameworks. Ниже показано окно в трёх вариантах с контентом для проектов на Java/Kotlin, Python и JavaScript/TypeScript.

Архитектурная группировка:

• Adapter — реализация паттерна «Адаптер»;

• Bean — объекты, управляемые соответствующими фреймворками по паттерну IoC;

• Bridge — реализация паттерна «Мост» между тем, «что делаем», и «как делаем»;

• Config — конфигурационные параметры, конфигурационные элементы кода;

• Data — все выделенные разными фреймворками структуры данных, используемые как транспортные объекты или объекты для обеспечения персистентности;

• DataSource — все выделенные фреймворками объекты, рассматриваемые как источники данных;

• Endpoint — все точки взаимодействия внешнего мира с системой без визуальных форм;

• Entry — точки старта приложений;

• Extension — значимые реализованные расширения, такие как хуки, аспекты и т. д.;

• Factory — выделенные механизмы порождения других объектов;

• Integration — все точки взаимодействия приложения с другими приложениями или источниками данных;

• Interaction — механизмы управления stateful-взаимодействием;

• Security — все элементы кода, связанные с управлением доступом к элементам ��риложения или данным;

• Task — описания единичных коротких действий и/или работ;

• TestCase — тесты кода и/или тестовые сценарии;

• Transaction — элементы кода, обеспечивающие транзакционные механизмы;

• View — функциональность визуальной работы с данными.

Навигация от элементов окна:

• одинарный клик на листовом элементе — переход в редактор кода;

• двойной клик — переход в окно Explorer.

Функциональность окна Solutions работает одинаково для Community- и PRO-версий GigaIDE.

Frameworks: из чего сделано

Всё, что мы обсудили, относится к ситуации, когда, глядя на зависимости, вы по их названиям узнаёте фреймворк. Но проблема в том, что их очень много, а новые участники проекта любят приносить новые, так что никто не знает весь возможный «зоопарк». Однако есливы знаете используемые микроархитектурные решения, то естественно задаться вопросом: «А с помощью чего они реализованы?»

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

Подробнее про окно Frameworks

Окно Frameworks расположено слева. Оно может делить западную часть окна приложения по высоте с другими окнами, такими как Project или Solutions. Ниже показано окно в трёх вариантах для разных языков.

Да, сейчас для Java/Kotlin мы распознаём 47 фреймворков, для Python — только 11, а для JS/TS — 5.

Навигация во Frameworks организована по аналогии с окном Solutions:

• одинарный клик на листовом элементе — переход в редактор кода;

• двойной клик — переход в окно Explorer.

Функциональность окна Frameworks работает одинаково для Community- и PRO-версий GigaIDE.

Промежуточный итог

Таким образом, пользователи GigaIDE получают два новых инструмента навигации и, кроме ответа на вопрос «что сделано?» (в окне Project), получают ответы на два следующих логических вопроса: «как это сделано?» (в окне Solutions) и «из чего сделано?» (в окне Frameworks).

Explorer: когда нужно подробнее

Но эти ответы, конечно, не могут быть достаточно детальными. Причина в том, что окно, будучи предназначенным для навигации и вытянутым вертикально (чтобы вмещать как можно больше объектов), просто не имеет необходимой ширины, чтобы удобно отображать глубокую иерархию или детальную информацию. Из него логично перейти либо к соответствующей точке кода, либо… в ещё одно окно, которое может предоставлять более насыщенную контекстом информацию по однородной группе объектов и содержать необходимые инструменты. Такие окна для runtime уже есть — например, Services, или окна для работы с версиями — Git.

Для микроархитектурных элементов или элементов фреймворков мы добавили ещё одно окно. Если одинарный клик на листовом элементе Solutions или Frameworks открывает соответствующий элемент в коде, то двойной клик на листовом или одинарный на промежуточном элементе открывает окно Explorer.

> Что можно найти или сделать через Explorer

Окно Explorer имеет две зоны, разделенные слайдером. Левая часть одинакова для версий GigaIDE PRO и GigaIDE Community и включает расширенную информацию по элементам из окон Frameworks и Solutions. Например, для Java выводится список точек входа в приложение, список типов-репозиториев и их методов.

В правой части размещаются дополнительные инструменты. В Community-версии по умолчанию доступны только просмотр кода элемента и параметров аннотаций и декораторов.

Контекстная навигация: от частного к общему или другому частному

Но это всё — «декомпозирующая» навигация «от общего к частному». В то же время, возможно, самая популярная кнопка на панели Project — это Select Opened File. Она перемещает вас в проекте к модулю, где расположен открытый файл, когда нужно переключиться обратно «от частного к общему».

Аналогично, когда мы говорим о навигации внутри контента фреймворка или конкретного архитектурного паттерна, нам нужна возможность перемещаться между связанными элементами в привязке либо к элементу фреймворка, либо к микроархитектурной сути элемента кода. Эту задачу мы решали с использованием контекстных навигационных элементов, доступных по gutter-иконкам. Да, JetBrains решала эту задачу, в том числе расширяя содержимое окна Structure, но, к сожалению, это окно либо ограничивает обзор своего содержимого, либо уменьшает ширину редактора кода.

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

> Примеры контекстной навигации из редактора кода

Пример контекстной навигации, похожей на реализованную в IntelliJ IDEA Ultimate для перехода по autowired-кандидатам (Spring).

Пример контекстной организации с выводом структуры объектов, участвующих в JPQL-запросе

Пример навигации c уровня типа по всем связанным объектам представлен на рисунке ниже:

Контекстная навигация в GigaIDE Community ограничена только возможностью перехода в окна Solutions и Frameworks.

На этом всё об инструментах навигации. Резюмируем: в GigaIDE можно смотреть на код с трёх разных сторон (Project, Solutions, Frameworks) и эффективно углубляться в детали (Explorer, контекстная навигация).

А как вы ориентируетесь в больших проектах? Есть ли любимые приемы или плагины? Делитесь опытом в комментариях, будет интересно почитать!

По всем вопросам, связанным с работой GigaIDE, обращайтесь в поддержку: https://gitverse.ru/support.

Автор: Андрей Слекеничс, PO GIGA IDE