Логика — служанка воли
Декларативные механизмы — СКД, функциональные опции, расширения — наступают. Всё чаще бизнес-заказчик требует: «Не пишите код, дайте настроить». Мы (разработчики) с готовностью подчиняем логику этой воле. Но за удобством скрываются ловушки, которые проявляются через полгода. Эта статья — не про «как сделать отчёт в СКД», а про то, почему ваш красивый декларативный механизм может внезапно убить производительность и как отлаживать то, что не отлаживается.
Декларативный тренд: почему логика стала служанкой
Тренд последних лет — смещение акцента с написания процедур на настройку правил. Платформа активно развивает механизмы, позволяющие бизнес-аналитикам и даже опытным пользователям влиять на логику без глубокого программирования. Управляемые формы, СКД, расширения конфигурации, функциональные опции, бизнес-процессы — всё это снижает порог входа для настройки, но одновременно уводит логику из-под прямого контроля разработчика.
Ключевой тезис: Декларативная парадигма в 1С — это не «кнопка для ленивых», а другая модель мышления. Она требует от разработчика не меньше понимания «под капотом», чем написание кода. Игнорирование этого — главная причина будущих инцидентов.
Рассмотрим на примере самой популярной декларативной технологии — системы компоновки данных (СКД). Разработчик создаёт схему, пользователь настраивает отборы, группировки, показатели. Воля пользователя выполнена. Но что происходит на уровне выполнения запроса? Как СКД преобразует настройки в SQL-подобный текст? И где здесь скрыты подводные камни?
СКД: механика под капотом
Как схема превращается в запрос
Когда пользователь изменяет настройки отчёта (добавляет поле, меняет фильтр), СКД не вызывает ваш код — она строит новый текст запроса на основе схемы и текущих настроек. Внутри это:
// Псевдокод: как СКД использует конструктор запроса
// Реальный объект — ПостроительОтчета (1С:Предприятие)
Построитель = БухгалтерскиеОтчеты.СоздатьПостроительОтчета();
Построитель.УстановитьПользовательскиеНастройки(НастройкиПользователя);
ТекстЗапроса = Построитель.ПолучитьТекстЗапроса();То, что возвращает ПолучитьТекстЗапроса(), — это полноценный запрос к базе данных на стороне сервера. Никто не проверяет, что ваша схема содержит Поле.Поле.ВнешнееСоединение, которое порождает JOIN из трёх таблиц, когда пользователь решает сгруппировать по этому полю. Производительность становится служанкой настроек, а не вашей воли.
Ловушка №1. Неявные множественные JOIN
Допустим, ваш отчёт по продажам включает поле «Контрагент.ОсновнойМенеджер.ФИО». В схеме СКД вы указали путь к этому полю через вложенную ссылку. При любой попытке использовать это поле в настройках (даже если оно скрыто в макете, а пользователь добавил его через «Ещё»), СКД порождает цепочку JOIN:
- Документ.Реализация -> Справочник.Контрагенты (LEFT JOIN)
- Справочник.Контрагенты -> Справочник.Менеджеры (LEFT JOIN)
Для 10 тысяч строк — это терпимо. Для 500 тысяч — полный обвал на СУБД. И самое неприятное: текст запроса, генерируемый СКД, почти невозможно «подсмотреть» стандартными средствами (только через ПолучитьТекстЗапроса после установки конкретных настроек, что делают не все).
Предупреждение: Если вы используете СКД с полями, содержащими более одного уровня вложенности (например, «Организация.ЮрЛицо.ИНН»), обязательно тестируйте отчёт на максимальном объёме данных с теми настройками, которые реально будут применять пользователи. Иначе «воля» одного человека может положить сервер всем.
Ловушка №2. Отладка декларативной логики — почти невозможна
Когда логика зашита в коде, вы можете поставить точку останова, проверить переменные, пройти пошагово. В СКД или в обработчике условного оформления управляемой формы точки останова нет. Вы видите только результат. Причём результат может зависеть от контекста выполнения (клиент/сервер, отключение повторов запросов и т.д.).
Пример: условное оформление списка значений
Настройка условного оформления управляемой формы — тоже декларация: «Если поле = 'Критично', то цвет фона красный». Кажется, элементарно. Но если условие не срабатывает, вы не можете войти в отладчик. Приходится перебирать варианты:
- Правильно ли указан путь к данным?
- Не влияет ли порядок применения других элементов оформления?
- Не кешируется ли результат на клиенте?
В коде эта же задача решалась бы процедурой с парой строк, которую можно оттрассировать.
Что делать прямо сейчас: чек-лист для разработчика
Тренд «логика — служанка воли» не отменить, но в вашей власти не становиться рабом собственных настроек. Вот конкретные шаги для специалиста с опытом от 5 лет:
- 1. Профилируйте запросы СКД. Включайте
ПолучитьТекстЗапроса()в тесты. Сравнивайте текст запроса при базовых настройках и при самых «тяжёлых» комбинациях пользовательских фильтров. - 2. Используйте внешние соединения осознанно. Если поле «Менеджер» реально нужно в 10% случаев, заведите на схеме вычисляемое поле, которое возвращает «%(ВычислитьВнешнееВыражение)» или используйте таблицу-посредник. Не кладите вложенные ссылки без надобности.
- 3. Тестируйте производительность на объёме. Подготовьте тестовые данные: 500 тыс. записей в основной таблице и 50 тыс. записей в справочниках. Прогоните отчёт с каждым видом настройки. Засеките время.
- 4. Разделите декларацию и код. Если логика выходит за рамки простой фильтрации (например, нужен расчёт последовательности, работа с временными периодами) — пишите код. СКД не для всего.
- 5. Обучите пользователей. Объясните бизнес-заказчику, что настройка отчёта — это не нажатие трёх кнопок. Каждое добавленное поле может замедлить систему. Пусть воля будет осознанной.
Типичные ошибки (и как их избежать)
| Ошибка | Последствия | Решение |
|---|---|---|
| Использование вложенных ссылок в СКД без анализа плана запроса | Скрытые LEFT JOIN → ORA-01652 / вытеснение tempdb | Проверять ПолучитьТекстЗапроса() и использовать «Вычислить» для редких полей |
| Добавление условного оформления через редактор без понимания условия | Оформление не работает, и вы не можете отладить | Для нетривиальных условий (<2-3 лог. оператора) пишите небольшую функцию в общем модуле и используйте её в вычисляемом поле |
| Попытка реализовать бизнес-логику через функциональные опции с выключаемыми реквизитами | Реквизиты остаются в метаданных, занимают место, а при переключении могут быть неучтённые индексы | Функциональные опции не панацея. Если реквизит требуется в редких конфигурациях, выносите его в расширение, а не плодите неиспользуемые поля |
Последняя строка таблицы — частая ошибка. Функциональные опции скрывают реквизит из формы, но он остаётся в таблице базы данных. При этом СУБД не знает, что столбец не нужен, и индексы не строятся по умолчанию. Когда опция включается — производительность падает, потому что выборка идёт по неиндексированному полю. Вывод: использовать функциональные опции только для метаданных, где объём данных минимален, а включение/выключение редко.
Резюме
Тренд «логика — служанка воли» в 1С — это движение в сторону конфигурируемости, но без понимания внутренней кухни он приводит к катастрофам производительности и невозможности отладки. Разработчик не должен отказываться от кода полностью. Декларативные механизмы сильны в своей нише: простые отчёты, условное оформление, настройка печати. Как только логика становится нетривиальной — код остаётся единственным надёжным инструментом. Помните: воля пользователя требует контекста, и этот контекст создаёте вы.
Попробовать НОПик →