Разработка в 1С часто сводится к дилемме: быстро решить задачу, влезая в типовую конфигурацию, или сохранить «чистоту» кода, рискуя получить недовольство пользователя из-за долгого внедрения. С появлением механизма расширений баланс сдвинулся в пользу второго варианта: теперь можно писать доработки, не ломая типовую. Но и здесь есть подводные камни.
Подписки на события: must-have для разработчика
Вместо того чтобы переписывать модуль объекта, используйте подписки. Это уменьшает риск конфликтов при обновлении.
Процедура ПередЗаписью(Источник, Отказ, РежимЗаписи)
Если Источник.Сумма < 0 Тогда
Отказ = Истина;
Сообщить("Сумма документа не может быть отрицательной!");
КонецЕсли;
КонецПроцедуры
Раньше такую проверку часто вставляли прямо в модуль документа. Теперь это делается подпиской — и при обновлении типовой проверка не исчезнет.
Расширение форм: когда без этого не обойтись
Иногда бизнес требует добавить поле прямо в форму документа. Но стоит помнить: каждое расширение формы увеличивает риск «сломать» интерфейс. Лучший подход:
- добавить отдельную вкладку для своих реквизитов, а не вмешиваться в типовые;
- документировать изменения (README внутри расширения);
- протестировать на тестовой базе перед боевым обновлением.
Общие модули как библиотека
Хорошая практика — заводить в расширении общий модуль «Utils», куда складываются универсальные функции: логирование, преобразование дат, форматирование строк.
Функция ФорматДатаВСтроку(Дата) Экспорт
Возврат Формат(Дата, "ДФ='dd.MM.yyyy'");
КонецФункции
Такой модуль становится «мини-библиотекой», которую можно использовать во всех частях расширения.
Управление версиями
Обязательно фиксируйте версию расширения и изменения в нём. Даже короткий CHANGELOG.md внутри репозитория спасает, когда через полгода придётся объяснять, «почему у нас тут такая логика».
Пример записи:
v1.2.0 — добавлена проверка отрицательных сумм
v1.1.0 — оптимизирован запрос к регистру ПродажиПоСкладам
v1.0.0 — первая версия, логирование и базовые функции
Где чаще всего «сыпется» код
- Подписки на события при массовом перепроведении документов (нагрузка).
- Формы, где типовая структура изменилась после обновления.
- Запросы, которые привязаны к конкретным именам таблиц (при апгрейде БД поля могли переименоваться).
Лайфхаки из практики
- Проверяйте расширение на чистой базе — без ваших данных всё видно объективнее.
- Делайте авто-тесты на ключевые сценарии (даже простые).
- Никогда не храните бизнес-логику «в голове» — только в коде и документации.
Вывод
Расширения в 1С — это не просто «заплатки», а полноценный способ строить надёжную архитектуру. Если использовать подписки, общие модули и версионирование, то ваши доработки переживут не одно обновление и не сломают типовую.
