При сопровождении сильно кастомизированных систем на базе 1С:Зарплата и Управление Персоналом 3.1 перед разработчиком и руководителем проекта всегда встает дилемма: гнаться за новым функционалом или придерживаться стабильности. Ситуация осложняется тем, что фирма «1С» параллельно выпускает обновления для двух разных технологических веток. Разберем подробно, какой путь выбрать «истинному джедаю» 1С, чтобы минимизировать трудозатраты и обеспечить стабильную работу кадровой службы.
Для начала проанализируем, что именно предлагает нам вендор. В экосистеме ЗУП 3.1 существует два типа релизов:
3.1.27, а ранее — 3.1.23, 3.1.18 и 3.1.14. В этих версиях фирма «1С» гарантирует поддержку законодательства и исправление критических ошибок без внесения глобальных изменений в структуру метаданных.3.1.29 или 3.1.30. Здесь обкатываются новые интерфейсные решения, механизмы расчета и интеграционные возможности. Эти версии быстро сменяют друг друга, и поддержка предыдущей функциональной ветки прекращается почти сразу после выхода следующей.Рассмотрим ситуацию с точки зрения архитектора доработанной системы. Если конфигурация «переписана» (изменены типовые объекты, добавлены новые реквизиты в документы, пересмотрена логика проведения), любое обновление превращается в процедуру трехстороннего сравнения и объединения. В этом случае выбор ветки напрямую влияет на периодичность этих «мучений».
Выберем этот вариант, если наша цель — максимальная стабильность и предсказуемость. Посмотрим на преимущества этого подхода:
Минимизация текущих правок. Поскольку структура метаданных в LTS-ветке практически не меняется, обновление проходит максимально гладко. Вам не придется ежемесячно переписывать свои доработки из-за того, что типовая процедура РассчитатьЗарплату внезапно сменила количество параметров или переехала в другой общий модуль.
Меньше багов платформы. LTS-версии дольше сохраняют совместимость со старыми версиями платформы 8.3. Это избавляет от необходимости экстренно обновлять серверную часть и клиентские места, что в крупных организациях может занимать недели.
Однако проанализируем и обратную сторону. Когда срок поддержки LTS-ветки подходит к концу (обычно это происходит раз в год-полтора), нам придется совершить технологический прыжок. Переход, например, с 3.1.23 на 3.1.27 — это не просто обновление, а полноценный мини-проект. Нам придется столкнуться с накопленным объемом изменений за весь пропущенный период.
Разберем ситуацию, когда мы решаем обновляться регулярно на самые свежие версии. Этот путь часто выбирают те, кому критически важен новый функционал (например, новые возможности личного кабинета или специфические формы отчетности, которые в LTS могут появиться позже).
Равномерное распределение нагрузки. Обновляясь понемногу, но часто, мы «размазываем» трудозатраты программиста по календарю. Мы решаем небольшие конфликты кода ежемесячно, а не копим их полтора года.
Риски «сырых» решений. Выясним причину, по которой многие коллеги опасаются этого пути. В функциональных ветках часто встречаются программные ошибки, которые исправляются только в следующих патчах. Для доработанной конфигурации поиск причины ошибки усложняется: непонятно, это «косяк» вендора или конфликт с нашими изменениями.
Независимо от выбранной ветки, крайне важно соблюдать правила «хорошего тона» разработки в 1С. Посмотрим на пример того, как минимизировать проблемы при любом обновлении. Основной инструмент здесь — расширения конфигурации.
Рассмотрим сценарий: нам нужно изменить логику заполнения документа НачислениеЗарплаты. Вместо правки типового модуля, используем аннотацию &Вместо или &После в расширении:
&После("ОбработкаЗаполнения")
Процедура Мой_ОбработкаЗаполнения(ДанныеЗаполнения, СтандартнаяОбработка)
// Наша логика доработки
Если ТипЗнч(ДанныеЗаполнения) = Тип("СправочникСсылка.Сотрудники") Тогда
// Дополнительные действия
КонецЕсли;
КонецПроцедуры
Использование расширений позволяет оставить типовую конфигурацию на «замочке», что значительно упрощает техническую процедуру наката cfu-файла. Однако помните: в функциональных ветках имена процедур меняются чаще, и расширение может «отвалиться» из-за несовпадения имен перехватываемых методов.
Еще один важный момент — обработчики обновления. При переходе между LTS-ветками система выполняет сотни обработчиков за раз. Если в вашей доработанной базе нарушена целостность данных (например, вы программно удаляли записи регистров, которые типовая логика считает обязательными), обработчик может завершиться с ошибкой. Проанализируем это заранее, запуская обновление на копии с включенной отладкой.
Проанализировав опыт коллег и официальную политику сопровождения, мы можем сформулировать следующие рекомендации:
3.1.27.//+ ИмяРазработчика и //- ИмяРазработчика, чтобы при сравнении и объединении сразу видеть свои изменения.В конечном итоге, выбор ветки — это баланс между спокойствием сегодня и объемом работы завтра. Для переписанной конфигурации спокойствие сегодня обычно важнее, поэтому LTS — это выбор большинства профессионалов.