Ты открываешь конфигуратор 1С, ждёшь 3 минуты загрузки, случайно закрываешь вкладку с нужным модулем — и всё по новой. Знакомо? А теперь представь, что есть инструмент, где всё работает как в нормальной IDE: автодополнение, рефакторинг, git-интеграция и поиск по всему проекту за секунды. Это не фантастика — это 1C:EDT.
Что такое 1C:EDT и почему это не просто «новый конфигуратор» для 1С
1C:EDT (Enterprise Development Tools) — это полноценная среда разработки для платформы 1С:Предприятие, построенная на базе Eclipse. Фирма «1С» начала разрабатывать EDT ещё в 2014 году, и с тех пор инструмент прошёл долгий путь от сырого прототипа до реально рабочего продукта.
Главная идея простая: дать 1С-разработчикам те же возможности, что есть у Java- или Python-программистов. Нормальный редактор кода, система контроля версий, модульное тестирование, статический анализ. Всё то, о чём 1С-ники мечтали годами, глядя на коллег из других стеков.
Конфигуратор, который мы все знаем и «любим», не менялся концептуально с конца 90-х. Он монолитный, не поддерживает нормальную работу в команде и не умеет в современные практики разработки. EDT — это попытка 1С сделать шаг в XXI век.
Чем EDT отличается от обычного конфигуратора
Разница принципиальная. Конфигуратор хранит конфигурацию в бинарном формате — один большой файл CF или CF-пакет. EDT хранит конфигурацию в виде дерева XML-файлов и текстовых модулей, каждый объект — отдельный файл. Это открывает возможность нормальной работы с git.
- В конфигураторе нет нормального поиска по всему проекту — только Ctrl+F в одном модуле
- В EDT — полнотекстовый поиск по всей конфигурации за секунды
- В конфигураторе автодополнение работает через раз и не знает контекста
- В EDT — умное автодополнение с учётом типов и контекста
- В конфигураторе нет рефакторинга — переименование переменной вручную по всем модулям
- В EDT — переименование с автоматическим обновлением всех вхождений
- В конфигураторе нет статического анализа кода
- В EDT — встроенный анализатор ловит ошибки до запуска
Как устроена архитектура 1C:EDT изнутри — расширяемость как основной принцип
«Расширяемая» в названии — это не маркетинг, это архитектурное решение. EDT построена на платформе Eclipse, которая изначально спроектирована как система плагинов. Каждый компонент EDT — это плагин или набор плагинов.
Что это даёт на практике? Любой разработчик или компания может написать свой плагин для EDT и расширить функциональность среды. Хочешь интеграцию с Jira — пишешь плагин. Нужен специфический линтер для корпоративных стандартов кодирования — пишешь плагин. Нужна интеграция с корпоративным репозиторием — плагин.
На одном из моих проектов мы написали собственный плагин для проверки соответствия именований объектов внутренним стандартам компании — и это заняло меньше времени, чем я ожидал. Eclipse-архитектура реально удобна для таких вещей.
Вот как выглядит типичная структура проекта в EDT на файловой системе:
/МойПроект/
.project
.gitignore
src/
Configuration/
Configuration.mdo
Documents/
ПриходнаяНакладная/
ПриходнаяНакладная.mdo
Forms/
ФормаДокумента/
Module.bsl
Form.form
Ext/
ObjectModule.bsl
ManagerModule.bsl
Каждый модуль — отдельный .bsl файл. Это значит, что git diff покажет тебе конкретные изменённые строки в конкретном модуле, а не «конфигурация изменена».
Форматы файлов и BSL-язык
BSL (Built-in Script Language) — это и есть язык 1С, просто в EDT он живёт в отдельных файлах. Расширение .bsl стало стандартом для хранения кода 1С вне конфигуратора. Вокруг него выросла целая экосистема инструментов.
Файлы метаданных хранятся в формате .mdo (Metadata Object). Это XML-файлы, которые описывают структуру объектов: реквизиты, табличные части, формы, роли. Они читаемы человеком и прекрасно версионируются в git.
Установка и первый запуск 1C:EDT — что нужно знать заранее
EDT — бесплатный инструмент для зарегистрированных пользователей платформы 1С:Предприятие. Скачать можно с сайта releases.1c.ru. Но есть нюансы, которые сэкономят тебе несколько часов нервов.
Первое: EDT требует Java, причём конкретной версии. В комплекте идёт собственная JRE, но иногда она конфликтует с системной Java. Если EDT не запускается — первым делом проверяй переменные окружения JAVA_HOME.
Я лично столкнулся с этим, когда на рабочей машине стояло три разных JDK одновременно — EDT упорно не хотел стартовать, пока не почистил переменные окружения и не прописал путь явно. Потерял на это полтора часа.
Второе: EDT ест память как не в себя. Для комфортной работы нужно минимум 16 ГБ RAM, лучше 32 ГБ. Конфигурация типа ERP на 32 ГБ будет чувствовать себя нормально, на 16 ГБ — терпимо, на 8 ГБ — мучение.
- Минимум для небольших конфигураций: 8 ГБ RAM, 4 ядра CPU
- Комфортная работа: 16 ГБ RAM, 8 ядер CPU
- Для ERP и КА: 32 ГБ RAM, 12+ ядер CPU
- SSD обязателен — на HDD EDT работает невыносимо медленно
- Первый импорт конфигурации типа ERP занимает 30-60 минут
Третье: EDT и конфигуратор — это параллельные миры, которые нужно синхронизировать. Ты можешь работать в EDT и выгружать изменения в конфигуратор, или наоборот. Но делать это нужно осознанно.
Импорт существующей конфигурации в EDT
Если у тебя уже есть рабочая конфигурация в конфигураторе, её нужно импортировать в EDT. Процесс несложный, но требует времени:
// Шаги импорта конфигурации:
// 1. Выгрузить конфигурацию из конфигуратора в файлы XML
// (Конфигурация → Выгрузить конфигурацию в файлы)
// 2. В EDT: File → Import → 1C:Enterprise → Конфигурация из файлов
// 3. Указать папку с выгруженными файлами
// 4. Дождаться индексации (для УТ ~15 мин, для ERP ~60 мин)
// Или через командную строку EDT:
ring edt@2024.3 workspace import --workspace ./workspace
--project ./МойПроект
--configuration-files ./src
После импорта EDT проиндексирует всю конфигурацию и покажет список ошибок и предупреждений. Не пугайся — в типовых конфигурациях EDT находит сотни предупреждений. Большинство из них — стилистические замечания, не критичные ошибки.
Реальные возможности 1C:EDT в работе разработчика на 1С
Хватит теории. Давай посмотрим, как EDT меняет повседневную работу 1С-разработчика на конкретных примерах.
Статический анализ кода и встроенный линтер
EDT автоматически проверяет код на ошибки в режиме реального времени. Ещё не запустил — а уже видишь подчёркивание: «переменная не используется», «метод не существует», «неверный тип параметра».
Пример: пишешь обращение к реквизиту документа:
&НаСервере
Процедура ЗаполнитьТаблицуНаСервере(ДокументОбъект)
// EDT сразу подскажет, если реквизита нет в метаданных
Если ДокументОбъект.СуммаДокументаБезНДС > 0 Тогда
// Подчеркнёт красным, если такого реквизита нет
ДокументОбъект.Статус = Перечисления.СтатусыДокументов.Подтверждён;
КонецЕсли;
КонецПроцедуры
В конфигураторе такую ошибку ты найдёшь только при попытке записать объект или при тестировании. В EDT — сразу, в момент написания кода. Это экономит реальное время.
Рефакторинг — то, чего не было никогда
Вот сценарий из жизни: тебе нужно переименовать общую функцию, которая используется в 47 модулях. В конфигураторе это — Ctrl+H в каждом модуле по очереди, или глобальная замена с риском сломать что-то лишнее.
В EDT это выглядит так:
// Кликаешь правой кнопкой на имени функции
// Выбираешь Refactor → Rename
// Вводишь новое имя
// EDT показывает предпросмотр всех изменений во всех файлах
// Подтверждаешь — и все 47 вхождений переименованы атомарно
// До рефакторинга:
Функция РассчитатьСуммуСНДС(Сумма, СтавкаНДС)
Возврат Сумма * (1 + СтавкаНДС / 100);
КонецФункции
// После рефакторинга (новое имя во всех модулях):
Функция ВычислитьСуммуВключаяНДС(Сумма, СтавкаНДС)
Возврат Сумма * (1 + СтавкаНДС / 100);
КонецФункции
Помню случай — разработчик из команды наших клиентов рассказывал, что переименование подсистемы в конфигурации на 200+ объектов в конфигураторе занимало у него полдня. В EDT — 15 минут с проверкой. На крупных проектах рефакторинг в EDT экономит часы работы.
Интеграция с Git в 1C:EDT
Это, пожалуй, главная причина, по которой команды переходят на EDT. Нормальная работа с git — это не роскошь, это базовая необходимость при командной разработке.
Типичный workflow команды из 5 разработчиков на 1С с EDT и git:
- Каждый разработчик работает в своей ветке (feature branch)
- При создании задачи — создаётся ветка от develop
- Изменения коммитятся небольшими осмысленными коммитами
- Перед мержем — code review через pull request
- EDT показывает diff на уровне строк кода, не на уровне «файл изменён»
- Конфликты разрешаются в merge tool — визуально, по строкам
- История изменений хранится вечно — можно найти, кто и когда сломал
Пример .gitignore для EDT-проекта:
# EDT служебные файлы
.metadata/
.settings/
*.bak
# Временные файлы платформы
*.cf
*.cfu
# Локальные настройки
.project.local
launches/
Экосистема вокруг 1C:EDT — плагины, инструменты, сообщество
Одно из главных преимуществ EDT — открытая экосистема. Вокруг инструмента выросло сообщество, которое создаёт дополнительные инструменты и плагины.
BSL Language Server и VS Code
Это отдельная история, которая выросла из EDT. BSL Language Server — это open-source реализация Language Server Protocol для языка 1С. Он позволяет использовать подсветку синтаксиса, автодополнение и статический анализ кода 1С прямо в VS Code.
Многие разработчики используют такой гибридный подход: основная разработка в EDT, быстрое редактирование отдельных модулей — в VS Code с BSL Language Server. VS Code запускается мгновенно, EDT — минуты.
SonarQube для 1С
Существует плагин SonarQube для анализа кода 1С, который интегрируется с EDT-проектами. Он позволяет настроить автоматическую проверку качества кода в CI/CD пайплайне.
Типичные метрики, которые отслеживают команды:
- Количество критических ошибок в коде (цель — 0)
- Покрытие кода тестами (реалистичная цель для 1С — 20-40%)
- Технический долг в часах
- Дублирование кода (процент)
- Сложность методов (цикломатическая сложность)
Vanessa Automation и тестирование
EDT открыл дорогу для нормального тестирования 1С-решений. Vanessa Automation — это фреймворк для BDD-тестирования на 1С, который прекрасно интегрируется с EDT и git.
Пример простого теста на языке Gherkin для 1С:
# language: ru
Функционал: Создание приходной накладной
Сценарий: Успешное создание накладной с корректными данными
Дано Я открываю форму нового документа "ПриходнаяНакладная"
Когда Я заполняю реквизит "Контрагент" значением "ООО Поставщик"
И Я добавляю строку в табличную часть "Товары"
И Я заполняю колонку "Номенклатура" значением "Товар тестовый"
И Я заполняю колонку "Количество" значением "10"
И Я заполняю колонку "Цена" значением "1000"
Тогда Сумма документа должна быть равна "10000"
И Документ должен успешно записаться
Сложности перехода на 1C:EDT — честно о проблемах
Было бы нечестно рассказывать только о плюсах. EDT — инструмент с характером, и переход на него требует времени и усилий.
Производительность EDT на больших конфигурациях
Главная боль EDT — это скорость работы с тяжёлыми конфигурациями. ERP 2.5 или Комплексная автоматизация 2.5 в EDT на среднем железе работают ощутимо медленнее, чем в конфигураторе.
Цифры из реальной практики: на машине с Intel Core i7-12700, 32 ГБ RAM, NVMe SSD:
- Запуск EDT с проектом ERP 2.5 — около 4-5 минут
- Полная индексация после обновления — 15-20 минут
- Поиск по всей конфигурации — 3-8 секунд
- Автодополнение в сложных контекстах — 1-3 секунды задержки
- Рефакторинг переименования в 50+ файлах — 30-60 секунд
Для небольших конфигураций (УТ, Бухгалтерия) всё значительно быстрее. Там EDT работает вполне комфортно даже на 16 ГБ RAM.
Кривая обучения и смена парадигмы
Разработчик, который 10 лет работал в конфигураторе, первые 2-3 недели в EDT будет чувствовать себя некомфортно. Интерфейс Eclipse непривычный, концепции другие, горячие клавиши другие.
Честно? Я раньше думал, что переход займёт пару дней — посмотришь пару видео, и готово. Нет. Первые две недели реально работаешь медленнее, чем в конфигураторе. Это нужно просто принять и пережить.
Типичные вопросы новичка в EDT:
- «Где запустить 1С?» — EDT не запускает 1С напрямую, нужно настроить launch configuration
- «Как обновить конфигурацию базы?» — через специальный инструмент синхронизации
- «Где дерево метаданных?» — в панели Package Explorer, структура другая
- «Как сделать Ctrl+Z?» — работает, но история изменений в EDT глубже
- «Почему EDT подчёркивает рабочий код?» — возможно, не подтянулись зависимости
По опыту, через месяц активной работы разработчики уже не хотят возвращаться в конфигуратор. Но этот месяц нужно пережить.
Совместимость с типовыми конфигурациями и обновлениями
Ещё одна реальная проблема: обновление типовых конфигураций через EDT — это отдельный квест. Если ты ведёшь разработку в EDT, а обновления от 1С приходят в виде CF-файлов, нужно выстроить процесс конвертации и мержа.
Схема работы, которая прижилась у многих команд:
// Процесс обновления типовой конфигурации с EDT + git:
// 1. Создать ветку для обновления
// git checkout -b update/1c-erp-2.5.15
// 2. Выгрузить новую типовую в файлы через конфигуратор
// ring edt@2024.3 workspace export ...
// 3. Скопировать файлы типовой в ветку
// 4. Сделать git merge с веткой разработки
// git merge develop
// 5. Разрешить конфликты в EDT merge tool
// (визуально, по строкам кода)
// 6. Прогнать тесты, убедиться что всё работает
// 7. Смержить в develop
// git checkout develop && git merge update/1c-erp-2.5.15
Этот процесс сложнее, чем «нажать обновить в конфигураторе», но зато ты видишь каждое изменение и контролируешь процесс. Больше никаких «обновление прошло, но что-то сломалось, и мы не знаем что».
Кому стоит переходить на 1C:EDT прямо сейчас — практические рекомендации
EDT — не серебряная пуля и не замена конфигуратора для всех случаев жизни. Ладно, погнали по-честному разберём, кому переход оправдан, а кому — пока нет.
EDT однозначно нужен если
- В команде больше 2-3 разработчиков, работающих над одной конфигурацией
- Ведётся доработка типовых конфигураций (УТ, ERP, КА) и важно отслеживать изменения
- Нужен code review — невозможен без нормальной системы контроля версий
- Планируется CI/CD пайплайн с автоматическим тестированием
- Конфигурация активно развивается и нужен рефакторинг
- Команда хочет применять современные практики разработки
Можно подождать если
- Одиночный разработчик, небольшая конфигурация, редкие изменения
- Работаешь только с типовыми конфигурациями без доработок
- Железо слабее 16 ГБ RAM — EDT будет мучением
- Дедлайн горит и нет времени на освоение нового инструмента
Как начать переход без боли
Лучшая стратегия — начать с нового проекта или нового модуля, а не пытаться перевести сразу всё. Вот пошаговый план:
- Шаг 1: Установить EDT, пройти официальный курс от 1С (есть бесплатно на портале 1С:ИТС)
- Шаг 2: Создать тестовый репозиторий git, импортировать в него копию рабочей конфигурации
- Шаг 3: Поработать в EDT параллельно с конфигуратором 2-3 недели на реальных задачах
- Шаг 4: Настроить базовый CI — хотя бы статический анализ при коммите
- Шаг 5: Перевести команду, провести внутреннее обучение
- Шаг 6: Настроить полный CI/CD с тестами и автодеплоем
Один из наших клиентов — компания из Новосибирска, 8 разработчиков на 1С — перешла на EDT за 3 месяца. Первый месяц — скрипели зубами, второй — привыкали, третий — уже не понимали, как жили без git. Количество «непонятно откуда взявшихся» багов после обновлений сократилось в разы — просто потому что теперь видно каждое изменение.
Стоимость перехода на EDT
Хорошая новость: сам EDT бесплатен для пользователей платформы 1С:Предприятие. Но есть косвенные затраты:
- Обновление железа, если текущего не хватает — от 50 000₽ за рабочую станцию
- Время на обучение команды — от 40 до 80 часов на разработчика
- Настройка инфраструктуры (git-сервер, CI/CD) — от 20 часов специалиста
- Потеря производительности в первый месяц — закладывай 20-30% снижение скорости
Инвестиция окупается примерно за 3-6 месяцев на командах от 3 человек — за счёт сокращения времени на code review, поиск багов и разрешение конфликтов при слиянии изменений.
Будущее 1C:EDT и тренды в 1С-разработке на 2026 год
1С активно развивает EDT — это уже не эксперимент, это стратегическое направление. В последних версиях появились серьёзные улучшения производительности, новые инструменты анализа и лучшая поддержка расширений.
Тренды, которые мы видим в 2026 году:
- EDT как стандарт для корпоративной разработки — крупные внедренцы переводят команды массово
- Рост экосистемы плагинов — появляются коммерческие плагины для специфических задач
- Интеграция с облачными сервисами — GitLab CI/CD, GitHub Actions для 1С стали нормой
- AI-ассистенты для BSL — несколько команд уже выпустили плагины с подсказками на основе LLM
- Рост спроса на разработчиков с опытом EDT — это уже требование в вакансиях
Я считаю, что разрыв между разработчиком с EDT+git и разработчиком только с конфигуратором будет только расти — и рынок это уже отражает. По нашим наблюдениям, разница в ставке составляет 15-25% в пользу тех, кто освоил EDT. Рынок уже голосует рублём.
Фирма «1С» на конференции Infostart Event 2025 прямо сказала: конфигуратор будет поддерживаться, но новые инструменты разработки будут появляться только в EDT. Это недвусмысленный сигнал о направлении движения.
Если ты руководитель команды разработки — закладывай переход на EDT в планы на 2026 год. Если ты разработчик — осваивай EDT сейчас, пока это конкурентное преимущество, а не базовое требование.
EDT — это не просто новый редактор кода. Это смена культуры разработки на 1С: от «одинокого героя с конфигуратором» к командной работе с нормальными инструментами, процессами и контролем качества. И эта смена уже происходит.
Если твоей команде нужна помощь с переходом на EDT, настройкой git-процессов или подбором 1С-разработчиков, которые уже работают в этой среде — заходи на koderion.ru. Это биржа специалистов 1С, где можно найти разработчиков с опытом EDT, или разместить своё резюме, если ты сам такой специалист. Без посредников, с проверенными профилями и реальными отзывами.