Многие разработчики при сопровождении и доработке типовых конфигураций (таких как «Бухгалтерия предприятия 3.0», «ERP» или «Управление торговлей») сталкиваются с неприятной ситуацией: после очередного обновления конфигурации код, написанный ранее, перестает работать. Причина банальна — используемая типовая функция исчезла из привычного общего модуля или изменила свое имя. В этой статье мы подробно разберем причины постоянного рефакторинга в решениях от 1С, выясним, зачем разработчики фирмы «1С» перемещают функции туда-сюда, и научимся проектировать свои решения так, чтобы они не «ломались» при каждом обновлении.
Рассмотрим типичную ситуацию. Для реализации печати штрихкода в кастомной обработке программист находит в типовом решении подходящую функцию. За последние полгода цепочка вызовов этой функции в «Бухгалтерии предприятия» могла выглядеть следующим образом:
// Сентябрь 2020:
ВКбазис = МенеджерОборудованияВызовСервера.ПодключитьВнешнююКомпонентуПечатиШтрихкода();
// Январь 2021:
ВКбазис = ГенерацияШтрихКодаВызовСервера.ПодключитьКомпонентуГенерацииИзображенияШтрихкода();
// Текущая версия:
ВКбазис = ГенерацияШтрихКода.ПодключитьКомпонентуГенерацииИзображенияШтрихкода();
На первый взгляд кажется, что это бессистемное переименование, но за каждым таким изменением стоит определенная логика развития Библиотеки стандартных подсистем (БСП) и Библиотеки подключаемого оборудования (БПО). Проанализируем основные причины таких «миграций».
Фирма «1С» стремится сделать свои конфигурации максимально модульными. Изначально функции генерации штрихкода могли находиться внутри БПО (модуль МенеджерОборудования), так как они требовались в основном для работы с принтерами этикеток. Однако со временем штрихкоды стали необходимы практически везде — от формирования QR-кодов в чеках до печати кодов маркировки в обычных накладных.
Выясним причину изменений: разработчики выделили генерацию штрихкодов в самостоятельную подсистему ГенерацияШтрихкода. Это позволило использовать этот функционал даже в тех решениях, где подсистема работы с торговым оборудованием полностью отсутствует. В результате функции «переехали» из общих модулей оборудования в специализированные модули новой подсистемы.
Обратите внимание на исчезновение постфикса ВызовСервера в именах модулей. В стандартах разработки 1С прописано требование минимизировать использование модулей с флагом «Вызов сервера». Это связано с тем, что каждое обращение к такому модулю создает дополнительную нагрузку на контекст и может быть неоптимальным.
Проанализируем ситуацию: когда логика переносится из модуля ГенерацияШтрихКодаВызовСервера в ГенерацияШтрихКода, это означает, что разработчики 1С пересмотрели архитектуру вызовов. Теперь предполагается, что вызов должен происходить внутри серверного контекста, а не напрямую с клиента. Это делает систему более стабильной и быстрой, но требует от нас исправления ссылок в коде.
Внедрение среды разработки 1C:EDT значительно упростило процесс рефакторинга для самих разработчиков фирмы «1С». Инструменты автоматизированного переименования позволяют одним кликом изменить название функции во всей огромной конфигурации (ERP или БП). Поскольку для внутренних команд 1С это стало «дешевой» операцией, они чаще прибегают к ней ради улучшения архитектуры, не всегда заботясь о совместимости с внешними расширениями или доработками.
Самая важная концепция, которую нужно усвоить программисту 1С: не все экспортные функции предназначены для вашего использования. В общих модулях 1С существует четкое разделение кода на секции с помощью областей (#Область):
// Устарела на год или более.Рассмотрим пример из практики: если вы используете функцию из области СлужебныйПрограммныйИнтерфейс, вы автоматически становитесь «сам себе злобным буратино» (ССЗБ). Именно такие функции чаще всего «гуляют» между модулями.
Чтобы ваши доработки не ломались при каждом обновлении, придерживайтесь следующих правил:
Перед тем как вызвать функцию из общего модуля, загляните в его начало. Проверьте, в какой области находится метод. Если области не размечены (что бывает в старых модулях), ориентируйтесь на документацию к БСП на сайте ИТС. Если функции там нет — использовать ее рискованно.
Если вам необходимо использовать функционал, который часто меняется, не вызывайте его напрямую во всех 100 местах вашего кода. Создайте свой общий модуль (например, _МойАдаптерБСП) и опишите в нем одну функцию-обертку. Проанализируем пример:
// В вашем модуле _МойАдаптерБСП
Функция ПодключитьКомпонентуШтрихкода() Экспорт
// Если 1С снова поменяет модуль, вы исправите это только в ОДНОМ месте
Возврат ГенерацияШтрихкода.ПодключитьКомпонентуГенерацииИзображенияШтрихкода();
КонецФункции
Если вам нужна небольшая вспомогательная функция из служебных разделов БСП, иногда проще и надежнее скопировать ее код в свой модуль (с соблюдением авторских прав, разумеется). Это избавит вас от зависимости от «гуляющих» модулей 1С. Однако помните, что в этом случае вы берете на себя ответственность за обновление этого кода (например, если в нем найдут ошибку в новом релизе).
При обновлении конфигурации 1С всегда публикует список изменений. Для разработчиков наиболее важны разделы, касающиеся библиотек БСП и БПО. Там всегда указывается: «Функция X была заменена на Y в связи с переходом на новую версию библиотеки». Регулярное чтение этих дайджестов — признак профессионального подхода.
Посмотрим на ситуацию шире: постоянный рефакторинг — это признак живого и развивающегося продукта. Фирма «1С» избавляется от «легаси» (устаревшего кода), переходит на Native API и Linux-совместимость. Наша задача как разработчиков — не ворчать на изменения, а использовать правильные архитектурные подходы для минимизации последствий этих изменений.