О чем статья
Когда разработчики переходят из конфигуратора в EDT, обычно быстро всплывают одни и те же претензии: где-то конфигуратор быстрее, где-то привычнее, где-то в EDT не хватает маленькой команды, а отдельные сценарии приходится делать обходным путем.
Но у EDT есть важное отличие: это Eclipse-среда, где плагины являются родным механизмом расширения IDE. Они могут встраиваться в меню, редакторы, подсказки, проверки и работу с проектами. В конфигураторе внешние инструменты тоже есть, но чаще живут сбоку и на больших конфигурациях нередко упираются в заметные тормоза.
В статье покажу несколько таких доработок и подробнее разберу плагин, который закрывает одну из самых заметных болей EDT: работу с контекстом расширений, внешних обработок и внешних отчетов.
Конфигуратор и EDT: честно о плюсах и минусах
Я не хочу сводить разговор к "старое против нового". У конфигуратора до сих пор есть сильные стороны, а у EDT хватает тяжелых мест.
Конфигуратор часто выигрывает как инструмент "сел и быстро сделал": быстрее запускается, быстрее откликается в типовых операциях и обычно требует меньше оперативной памяти. Для срочных разборов, небольших правок и привычных сценариев это все еще сильный аргумент.
EDT тяжелее: больше памяти, дольше старт, фоновые процессы, требования к workspace. Если сравнивать только скорость реакции IDE, конфигуратор во многих случаях ощущается легче.
Зато EDT лучше меняется под разработчика. Раньше вход в разработку EDT-плагинов был почти невозможен для обычного 1Сника: Eclipse, OSGi, внутренние API, Tycho/Maven, target platform. Сейчас Codex с подпиской Pro может за месяц помочь закрыть большую часть прикладных неудобств: найти API, собрать плагин, встроить команду в меню, добавить настройку, подсветку, контекст или update site.
Не каждый такой плагин будет идеальным. Его все равно нужно проверять, тестировать на конкретных версиях EDT и аккуратно использовать. Но сам факт, что среду теперь можно гибко менять под себя, меняет психологию работы. Не обязательно ждать, пока маленькую правку когда-нибудь добавят в EDT. Если нужна команда, подсветка, контекст или автоматизация, это можно сделать самостоятельно.
Хочу показать, что получилось конкретно у меня.
EDT Extension Tweaks: что это
EDT Extension Tweaks рассчитан на рабочую область, где рядом живут:
- основная конфигурация;
- одно или несколько расширений;
- внешние обработки;
- внешние отчеты;
- иногда еще и вспомогательные тестовые проекты.
В обычной EDT такие проекты не всегда видят друг друга так, как разработчику хотелось бы. Есть метаданные в расширении. Внешняя обработка их не видит. Или допустим, есть расширение для тестов. Оно не взаимодействует с контекстом расширения, которое надо протестировать. Схемы СКД по данным расширения? - Пожалуйста!
Плагин закрывает эту боль несколькими точечными возможностями:
Общий контекст EDT
Главная возможность плагина: команда Настроить контекст EDT для проектов расширений, внешних обработок и внешних отчетов.
Здесь речь не просто про "подключить соседний проект". В реальной разработке часто есть расширение, которое добавляет свои общие модули, реквизиты, справочники или другие объекты. В режиме предприятия все это работает, но во внешней обработке, внешнем отчете или другом расширении такой контекст обычно недоступен для IDE.
Например, в расширении добавили новый объект или реквизит, а потом нужно быстро написать внешнюю обработку, которая к нему обращается. Или нужно сделать внешний отчет на СКД по метаданным, которые появились именно в расширении. В обычном сценарии начинаются обходные пути: писать запрос руками, проверять его через консоль запросов в режиме предприятия, временно добавлять отчет в само расширение, усложнять отладку.
EDT Extension Tweaks позволяет выбрать соседние проекты workspace, которые должны быть видимы текущему проекту как BSL-контекст. После этого экспортные общие модули, методы и метаданные выбранных проектов начинают участвовать в подсказках, навигации и анализе EDT.
Команда настройки контекста подключает соседние проекты как видимый BSL-контекст.
Практический эффект:
- внешняя обработка может обращаться к модулям расширения с нормальной контекстной подсказкой;
- другое расширение может видеть объекты, добавленные в соседнем расширении;
- внешние отчеты и обработки можно разрабатывать в EDT без временного переноса в расширение;
- переходы по объектам работают предсказуемее;
- меньше ложных ошибок там, где код корректен для реального рабочего контура.
После этого внешние обработки и расширения перестают выглядеть в EDT как отдельные проекты в вакууме.
Метаданные расширений в конструкторе запросов
Та же идея работает и для конструктора запросов.
Самый болезненный пример - СКД во внешнем отчете или обработке. Нужно построить отчет по данным, которые добавило расширение, но конструктор запроса не видит эти метаданные. В результате инструмент, который должен ускорять разработку, выключается именно там, где особенно нужен.
Плагин добавляет видимость метаданных связанных проектов в конструкторе запросов EDT. Можно открыть схему СКД во внешней обработке и работать с объектами расширения как с частью доступного контекста, а не переносить отчет в расширение только ради конструктора.
Отдельно интересно, что вложенные конструкторы запросов, открытые из условий и произвольных выражений, могут видеть временные таблицы, созданные в предыдущих пакетах текущего запроса.
Конструктор запросов получает более полный контекст проекта.
В ежедневной работе эффект простой: меньше ручного переписывания, меньше переключений между EDT и предприятием, меньше ситуаций "код работает, но IDE не помогает".
По сути, в этом сценарии EDT с плагином уже закрывает боль, которую в конфигураторе долго приходилось обходить вручную. В анонсе 1С на "Зазеркалье" доступность объектов расширений из внешних отчетов и обработок описывалась как планируемая доработка платформы. Здесь же это уже можно использовать в EDT через плагин.
Настройка обновления ИБ из EDT
Еще одна практичная возможность: команда Настроить обновляемые проекты во вкладке приложений EDT.
Она позволяет исключить выбранные проекты из цепочки обновления ИБ для конкретного приложения. Например, можно не трогать тяжелую основную конфигурацию, когда проверяешь отдельное расширение, или не обновлять проекты, которые сейчас вообще не относятся к текущей задаче.
Для больших workspace это заметно: меньше ожидания там, где обновление лишних проектов вообще не нужно.
&ИзменениеИКонтроль: форматирование и merge
Плагин также добавляет две полезные вещи для методов с &ИзменениеИКонтроль.
Первая: форматирование кода внутри блоков #Вставка / #КонецВставки по Ctrl+Shift+F. Важно, что форматируется именно содержимое вставки, а основной метод за пределами блока не переписывается.
Вторая: быстрый сценарий сравнения и объединения, когда EDT сообщает, что метод расширения разошелся с базовым методом.
Плагин открывает трехстороннее сравнение:
- слева текущий типовой метод;
- справа текущий метод расширения;
- ancestor собирается из метода расширения без блоков
#Вставка/#КонецВставкии с раскрытыми блоками#Удаление/#КонецУдаления.
Начальный результат строится от текущего типового метода, а поверх него накладываются существующие блоки вставки и удаления из расширения. После сохранения результат заменяет текст метода расширения.
Для `&ИзменениеИКонтроль` появляется более осмысленный сценарий обновления после изменения типового метода.
Это делает один из самых неприятных сценариев сопровождения расширений более управляемым.
Подсветка серверных вызовов
В клиентском BSL-коде плагин может подсвечивать обращения, которые EDT считает серверными вызовами.
Для вызовов через общий модуль подсвечивается и имя модуля, и вызываемый метод. Цвет и стиль можно настроить в параметрах плагина.
На практике это полезно именно как "трение в нужном месте": смотришь на клиентский код и сразу видишь потенциально дорогие переходы на сервер. Особенно в формах, где серверный вызов легко спрятать внутри привычного общего модуля.
Автоматическое переключение "Схема" и "Свойства"
Плагин также умеет переключать панели EDT в зависимости от активного редактора.
Когда активен BSL-редактор, открытая панель Свойства переключается на Схему. Когда активна форма, вкладка формы или навигатор, открытая Схема переключается обратно на Свойства.
Если в этом месте открыта другая панель, плагин ее не заменяет.
Такие вещи редко становятся главной причиной установки, но хорошо показывают направление: EDT можно допиливать под реальный ритм работы.
Почему это важно: плагин написан через AI
Отдельная часть истории: этот плагин почти полностью написан через Codex/ChatGPT.
Это не рекламная деталь, а важная часть истории: разработчик 1С может взять конкретную боль, с помощью AI разобраться во внутренних API EDT, собрать рабочий плагин, проверить его и опубликовать update site.
Да, это не отменяет инженерную ответственность: результат надо тестировать, профилировать и проверять на нужных версиях EDT. Но сам порог входа изменился радикально.
Еще несколько примеров
Quick Fixes for 1C:EDT
Quick Fixes добавляет меню с командами, которые исправляют типовые замечания стандартных проверок модуля одним действием.
Идея очень практичная: EDT умеет подсвечивать много однотипных проблем, но руками править их скучно и долго. Плагин автоматизирует такие операции:
- создать стандартные области;
- расставить области по порядку;
- перенести методы в корректные области;
- привести имена переменных к соглашениям;
- убрать лишние обращения к
ЭтотОбъект; - заменить устаревшее
ЭтаФорма; - добавить отсутствующие директивы на форме;
- удалить неиспользуемые методы и переменные;
- схлопнуть пустые строки.
Важный UX-момент: каждая операция делается как одна правка документа и откатывается через Ctrl+Z.
EDT Form Update
EDT Form Update закрывает отдельную боль расширений: пакетное обновление заимствованных форм после изменения форм в расширяемой конфигурации.
Без плагина такие формы часто приходится открывать и обновлять по одной. Плагин добавляет команду:
Проект -> Обновить формы расширения
После запуска он предлагает выбрать проект расширения, находит формы, для которых в основной конфигурации есть изменения, показывает список и позволяет обновить выбранные формы пакетно.
Это не революция, но очень хороший пример маленькой автоматизации, которая экономит время на повторяющейся операции.
Что в итоге
Все эти плагины складываются в одну картину: EDT перестает быть закрытой коробкой, с которой можно только спорить на форумах. Ее можно расширять под свой процесс.
Если не хватает контекста для внешних обработок, его можно добавить. Если конструктор запросов не видит нужные метаданные, можно расширить его поведение. Если не хватает команды в меню, ее можно написать. Да, внутренние API EDT могут меняться, а плагины надо тестировать на конкретных версиях. Но направление здоровое: разработчики 1С начинают не только пользоваться EDT, но и улучшать саму среду разработки.
Вступайте в нашу телеграмм-группу Инфостарт