Разработка с использованием расширений конфигурации в платформе 1С:Предприятие 8.3 стала стандартом де-факто для кастомизации типовых решений. Она позволяет сохранить конфигурацию поставщика на поддержке и упростить процесс последующих обновлений. Однако при активном внедрении расширений разработчики неизбежно сталкиваются с хаосом: как называть новые расширения, как именовать объекты внутри них и какую архитектуру выбрать — создать одно монолитное расширение или разделить доработки на десятки мелких?
В этой статье мы подробно разберем правила именования расширений, проанализируем стандарты фирмы «1С» и рассмотрим классическую дилемму архитектуры: «одно большое расширение против множества мелких».
Давать расширениям имена вроде Расш1, НовоеРасширение или Исправления_Новое — это путь к путанице и ошибкам администрирования. При разработке профессиональных расширений важно придерживаться системного подхода. Для соблюдения правил оформления и именования можно использовать готовые шаблоны для применения стандартов и методик разработки 1С.
Рекомендуемый шаблон для имени расширения выглядит следующим образом:
[ПрефиксОрганизации]_[ФункциональноеНаправление]
Рассмотрим примеры удачных названий:
Азот_ЛогистикаПродаж — доработка логистического контура для компании «Азот».ИТ_ИнтеграцияМаркетплейсы — интеграционный модуль для работы с внешними площадками.ККК_ЗарплатныйПроект — кастомные доработки подсистемы расчета зарплаты.Помимо имени самого расширения, крайне важно соблюдать правила именования объектов внутри него. Согласно требованиям «1С:Совместимо» и стандартам разработки фирмы «1С», необходимо соблюдать следующие правила:
УпаковкиТМЦ в расширении Логистика следует создать Лог_УпаковкиТМЦ.&Перед, &После и &Вместо.Рассмотрим пример правильного перехвата процедуры с использованием префикса:
&Вместо("РассчитатьСкидкиКарты")
Процедура Лог_РассчитатьСкидкиКарты(ДокументСсылка, ПараметрыСкидок)
// Выполняем предварительную подготовку данных
Лог_ПодготовитьДанныеДляСкидок(ДокументСсылка);
// Вызываем оригинальный метод конфигурации
ПродолжитьВызов(ДокументСсылка, ПараметрыСкидок);
// Выполняем пост-обработку результатов
Лог_ЗаписатьЛогСкидок(ДокументСсылка);
КонецПроцедуры
Многие разработчики делят расширения по именам (например, добавляя в конце слова _Адаптация или _Исправление). Однако платформа 1С, начиная с версии 8.3.10, имеет встроенный механизм разделения расширений по типам через свойство «Назначение расширения». Всего существует три варианта назначения:
Правильный выбор свойства назначения критически важен. Он определяет жесткую последовательность компиляции модулей и применения изменений в базе данных, минимизируя конфликты совместимости.
Среди разработчиков 1С не утихают споры о том, как лучше организовать доработки: объединить все изменения в одном крупном расширении («монолите») или разбить их на множество мелких точечных файлов.
Проанализируем обе концепции, их преимущества и недостатки.
При таком подходе абсолютно все доработки конфигурации ведутся в рамках одного единственного расширения.
Преимущества монолита:
РеализацияТоваровУслуг), он заимствуется в расширение всего один раз.Недостатки монолита:
Каждая отдельная задача или исправление ошибки оформляется в виде обособленного расширения.
Преимущества модульного подхода:
Недостатки модульного подхода:
&Вместо: Если два разных расширения попытаются перехватить один и тот же метод основной конфигурации через аннотацию &Вместо, применится только одно из них (в зависимости от порядка подключения), либо система выдаст критическую ошибку выполнения.Чтобы избежать крайностей, мы рекомендуем придерживаться сбалансированного гибридного подхода. Разделим доработки на логические группы и создадим расширения по функциональным подсистемам:
Исправление, куда помещаются только оперативные фиксы багов релизов от вендора. Оно регулярно очищается по мере выхода официальных обновлений конфигурации.Организация_Логистика (доработки склада, доставки, транспортных накладных).Организация_Маркетинг (интеграция с CRM, рассылки, скидочные системы).Организация_ИнтеграцияСайт (обмен данными с интернет-магазином).Такое деление позволяет соблюсти баланс: поддерживать высокую производительность системы, изолировать критические ошибки обновления и вести комфортную параллельную разработку несколькими программистами. Для своевременной проверки межмодульных связей и поиска некорректных вызовов в расширениях можно использовать инструмент для анализа состава расширений и поиска ошибок.