← На главную

В мире 1С:Предприятия мы часто сталкиваемся с необходимостью поддерживать актуальность наших информационных систем, и здесь традиционно на помощь приходят обновления типовых конфигураций. Однако, в последние годы все большую роль играют так называемые «расширения-патчи», которые выпускаются 1С для оперативного исправления ошибок. Мы рассмотрим подробно, почему 1С переходит к этой модели, какие проблемы она создает для нас, разработчиков и администраторов, и как мы можем эффективно управлять этим процессом, чтобы минимизировать риски и сложности.

Понимание механизма расширений-патчей от 1С

Расширения в 1С:Предприятии, появившиеся с версии платформы 8.3.5, изначально были задуманы как мощный инструмент для доработки конфигураций без изменения их основного кода. Это должно было упростить процесс обновления и сохранить поддержку типовых решений. Но со временем, особенно с появлением большого количества расширений-патчей от 1С, мы начали замечать, что этот инструмент, хоть и полезен, порождает новые сложности.

Что такое расширения-патчи и почему 1С их использует?

1С использует расширения-патчи, или «исправления», для оперативного устранения ошибок в типовых конфигурациях. Это позволяет не выпускать полноценное, объемное обновление при каждом найденном баге, а предоставлять исправления «на лету». Давайте проанализируем основные причины такого подхода:

1. Снижение частоты выпуска объемных релизов: Мы помним времена, когда 1С могла выпускать по три релиза одной конфигурации в течение недели, исправляя одно и добавляя новые ошибки. Патчи помогают снизить эту частоту, предоставляя более стабильные основные релизы.
2. Оперативность исправлений: Если обнаружена критическая ошибка, патч может быть выпущен гораздо быстрее, чем полноценный релиз, который требует более длительного цикла тестирования и подготовки.
3. Целевое воздействие: Патчи фокусируются на конкретной проблеме, не затрагивая широкий функционал, что в теории должно уменьшать риски побочных эффектов.

Жизненный цикл патчей: временность и интеграция в основной релиз

Важно понимать, что патчи представляют собой временное решение, своего рода «заплатку». В идеале, функционал, который исправляется патчем, со временем должен быть интегрирован в основной релиз конфигурации. После интеграции в основной релиз, соответствующий патч должен быть удален или отключен, поскольку его функционал уже реализован в базовой конфигурации.

Классификация расширений и порядок их применения

С версии платформы 8.3.10 1С ввела классификацию расширений по назначению, что помогает нам лучше понимать их роль:

1. «Исправление» (патч): Предназначено для устранения ошибок.
2. «Адаптация»: Используется для постоянных доработок, которые изменяют базовую логику типового решения.
3. «Дополнение»: Создано для внедрения нового функционала с минимальным влиянием на существующие механизмы.

Порядок применения этих расширений строго регламентирован: сначала применяются расширения типа "Исправление", затем "Адаптация", и в конце "Дополнение". Мы должны учитывать этот порядок при разработке и внедрении собственных расширений.

Основные проблемы, возникающие при использовании большого количества расширений-патчей

Хотя расширения и патчи имеют свои преимущества, их избыточное количество или некорректное использование порождает ряд проблем, с которыми мы сталкиваемся ежедневно.

1. Сложности сравнения и объединения доработок:

   Одна из наиболее острых проблем. Если мы изменяем конфигурацию, а в одном из расширений от 1С (или в другом нашем расширении) содержится изменение того же модуля или формы, нам предстоит трудоемкий процесс по поиску и слиянию доработок. В отличие от конфигурации, для расширений до сих пор нет корректного и удобного встроенного механизма сравнения/объединения. Это превращается в настоящий квест, особенно если у нас десятки собственных расширений, а с обновлением прилетает еще пара десятков патчей.

2. Конфликты между расширениями и собственными доработками:

   При большом количестве расширений, как типовых патчей, так и наших собственных, возрастает вероятность конфликтов. Мы можем изменить кусок кода в конфигурации или в своем расширении, а затем придет патч от 1С, который изменит тот же самый кусок. В лучшем случае система сразу упадет, и мы узнаем о проблеме. В худшем — функционал просто перестанет работать или будет работать некорректно, и нам придется долго искать причину. Это особенно вероятно, если патчи пишутся разными отделами 1С, которые могут быть недостаточно скоординированы. В некоторых случаях патч может прийти и отключить или перекрыть наши доработки, даже если он "не меняет функционал" в смысле добавления реквизитов, а только исправляет код.

3. Сложность администрирования:

   Когда количество расширений переваливает за 5-10, контроль над процессом их применения, актуальности и влияния становится крайне сложным. Если мы видим 40 или 150 расширений в одной базе, это может свидетельствовать о неоптимальном подходе. Мы теряем прозрачность: какие патчи актуальны, какие уже интегрированы в основной релиз и могут быть удалены, какие конфликтуют между собой.

4. Влияние на производительность:

   Хотя расширения призваны улучшать гибкость, их избыточное количество может негативно сказаться на производительности системы. Каждый подключенный модуль требует ресурсов, и при выполнении операций платформа должна учитывать логику всех примененных расширений. Мы должны анализировать и оптимизировать производительность расширений, чтобы избежать замедления работы.

5. Адаптация при обновлениях:

   После обновления типовой конфигурации наши собственные расширения могут перестать работать. Изменения в структурах данных, формах или модулях типовой конфигурации могут нарушить логику работы расширений, требуя их адаптации под новую версию. Это особенно актуально для форм и модулей, где 1С часто вносит изменения.

6. Ограничения расширений:

   Мы должны помнить, что расширение не может напрямую обращаться к некоторым объектам основной конфигурации. Иногда это требует переноса нужных объектов и кода в расширение, что увеличивает его объем и усложняет поддержку. Также существуют ограничения на добавление подчиненных систем, что может быть критично для комплексных доработок.

7. Отзыв и замена патчей:

   На практике мы видим, что 1С может отзывать один и тот же патч несколько раз. То есть, сегодня мы устанавливаем патч, завтра он отзывается, и вместо него прилетает новый, который затем снова может быть заменен. Это создает дополнительную неопределенность и требует внимательного мониторинга со стороны администраторов.

Эффективные подходы и решения для управления расширениями-патчами

Столкнувшись с вышеперечисленными проблемами, мы должны выработать стратегию по эффективному управлению расширениями-патчами. Рассмотрим основные рекомендации и решения.

1. Использование 1С:Enterprise Development Tools (EDT) для сравнения и объединения:

   Одним из ключевых инструментов, который помогает нам в работе с расширениями, является 1С:Enterprise Development Tools (EDT). В отличие от стандартного конфигуратора, EDT предоставляет более развитые возможности для сравнения и объединения, в том числе и для расширений. Мы можем использовать EDT для:

   • Сравнения конфигурации с расширением: EDT позволяет нам увидеть, какие объекты конфигурации были изменены или дополнены в расширении.
   • Сравнения различных версий расширений: Это помогает отслеживать изменения, внесенные в наши собственные расширения или в патчи 1С.
   • Анализа конфликтов: Хотя полное автоматическое слияние может быть недоступно, EDT значительно упрощает поиск мест потенциальных конфликтов, где типовая конфигурация, патч и наше расширение затрагивают один и тот же участок кода.

   Переход на EDT требует определенных усилий и освоения новой среды, но его функционал в долгосрочной перспективе окупает эти вложения, особенно для проектов с активной разработкой и множеством расширений.

2. Осторожное и осознанное применение патчей:

   Нам не обязательно устанавливать абсолютно все патчи, которые прилетают от 1С. Мы должны проявлять избирательность:

   • Выборочная установка: Внимательно изучаем описание каждого патча. Устанавливаем только те, которые исправляют ошибки, актуальные для нашего бизнеса или критичные для функциональности.
   • Отключение устаревших патчей: Если мы знаем, что функционал патча уже интегрирован в основной релиз конфигурации, или патч оказался "кривым" и был заменен более новой версией (как это бывает с отозванными патчами), мы должны его отключить или удалить. Это помогает снизить количество активных расширений и потенциальных конфликтов. Для этого обычно требуется монопольный режим и очистка кэша.
   • Понимание временного характера: Всегда помним, что патч — это временное решение. При выходе нового полноценного релиза конфигурации, мы ожидаем, что большая часть активных патчей будет интегрирована в него, и их можно будет удалить.
3. Правильное проектирование собственных расширений:

   Если мы разрабатываем собственные доработки в виде расширений, крайне важно следовать определенным правилам, чтобы не усугублять проблему и избежать конфликтов с патчами 1С:

   • Не плодите расширения без обоснованных причин: Хотя гибкость расширений велика, наличие 150 расширений — это избыточно. Для каждой задачи или подсистемы стараемся создавать одно логически связанное расширение. Контроль над 5-10 хорошо структурированными расширениями гораздо проще, чем над сотней мелких.
   • Используйте префиксы для методов и объектов: Чтобы избежать конфликтов имен (даже если мы думаем, что наше имя уникально), рекомендуется добавлять префиксы к названиям методов, переменных и даже объектов, которые мы добавляем в расширения. Например, вместо МояФункция() используем _МоеРасширение_МояФункция().
   • Предпочитайте &Перед и &После вместо &Вместо: При изменении модулей с помощью аннотаций в расширениях мы имеем выбор: &Перед (выполняется код перед типовым), &После (выполняется код после типового) и &Вместо (полностью заменяет типовой код). Мы должны использовать &Перед и &После как можно чаще, так как они более гибки и менее подвержены конфликтам при изменениях в типовой конфигурации. Аннотацию &Вместо мы используем только в крайних случаях, когда нет другого способа реализовать доработку, поскольку она полностью перекрывает типовой код и наиболее чувствительна к обновлениям.
   • Программные изменения форм: При доработке форм в расширениях предпочтительно делать изменения программно, а не полагаться на автоматическое обновление через "Обновить расширение формы". Программный подход дает нам больше контроля и стабильности, особенно когда 1С меняет структуру форм.
   • Размещение метаданных (МД) в расширениях: Современные версии платформы 1С позволяют нам добавлять в расширения новые объекты метаданных (например, реквизиты, документы, отчеты). Мы должны использовать эту возможность для изоляции наших доработок от основной конфигурации.
4. Администрирование и контроль:

   Для эффективного управления расширениями нам необходимы четкие процедуры и, возможно, дополнительные инструменты:

   • Применение внешних инструментов: Существуют специализированные инструменты (например, "обновлятор" конфигураций), которые могут помочь нам грамотно отслеживать, устанавливать и удалять устаревшие патчи перед обновлением конфигурации. Они автоматизируют рутинные операции и снижают вероятность ошибок.
   • Регулярная чистка кэша и удаление старых патчей: Мы должны регулярно выполнять чистку кэша 1С и удалять неактуальные или отозванные патчи. Это помогает избежать проблем с конфликтами внутренних идентификаторов объектов, которые могут возникать из-за копирования и модификации патчей 1С.
   • Работа в монопольном режиме: Многие операции с расширениями, такие как удаление старых патчей или очистка кэша, требуют выполнения в монопольном режиме. Мы должны планировать эти работы вне рабочего времени пользователей.
   • Снятие флага "Безопасный режим": В некоторых случаях для успешного применения расширения (особенно если оно выполняет операции, требующие повышенных прав) может потребоваться снятие флага "Безопасный режим". Мы должны делать это осознанно и только после тщательной проверки расширения.
5. Системы управления доработками:

   Для больших проектов с множеством расширений и активной разработкой целесообразно использовать системы управления доработками (например, доработанные конфигурации СППР или внешние системы контроля версий). В таких системах расширения хранятся с полной историей версий, и мы можем запрашивать установку конкретной или последней версии, что дает полный контроль над процессом.

Преимущества и обоснования использования расширений-патчей

Несмотря на все сложности, мы не можем отрицать и очевидные преимущества использования расширений-патчей, особенно для нас, как для разработчиков и администраторов:

• Оперативность исправления ошибок: Патчи позволяют 1С очень быстро реагировать на критические ошибки, что уменьшает время простоя системы и повышает стабильность работы для конечных пользователей.
• Снижение частоты выпусков объемных релизов: Для нас это означает меньше больших обновлений, которые могут быть рискованными и трудоемкими, особенно для сильно доработанных конфигураций.
• Удобство для доработанных конфигураций: Если наша конфигурация сильно изменена, каждое полноценное обновление — это трудоемкий процесс адаптации наших доработок под новую версию. Патчи, напротив, часто исправляют типовой код без необходимости переделывать наши доработки. В случае проблем, патч можно быстро отключить в два клика, что дает нам гибкость.
• Меньший размер скачиваемых файлов: Вместо скачивания многогигабайтных обновлений каждую неделю, патчи обычно занимают сотни килобайт, что значительно экономит трафик и время при обновлении.

Таким образом, механизм расширений в 1С:Предприятии — это мощный инструмент, который дает нам возможность дорабатывать типовые решения без снятия с поддержки. Однако, он требует от нас внимательного подхода к администрированию, управлению версиями и предотвращению конфликтов. Мы должны понимать его преимущества и недостатки, активно применять рекомендованные подходы и инструменты, чтобы обеспечить стабильную и эффективную работу наших информационных систем.