Дисциплина расширений 1С: четыре правила, чтобы обновление типовой не превращалось в аврал

12 июня 2026 · infolimp.ru

База на поддержке, доработки живут в расширениях, и поначалу это выглядит образцово: типовая не тронута, обновления ставятся. Через год расширений уже девять, три из них написаны людьми, которые в компании больше не работают, и перед каждым обновлением типовой сопровождение гадает: что из этого отвалится сегодня? Расширения избавили от снятия с поддержки, но хаос они умеют копить не хуже прямых доработок — просто он наступает позже. Разговор про базы на поддержке — типовые конфигурации; для самописных механика та же, но цена ошибок другая.

Откуда берётся хаос

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

Правило 1. Одно расширение — одна зона ответственности

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

Правило 2. «&Вместо» — крайняя мера, а не основной инструмент

Аннотация &Вместо полностью подменяет типовой метод: что бы вендор ни изменил в нём при обновлении, ваша копия об этом не узнает. Каждый &Вместо — это замороженный кусок чужого кода, который вы обязуетесь сопровождать сами. Поэтому порядок предпочтений такой: сначала &Перед и &После — они дополняют типовой код, не отменяя его; если без подмены никак — &Вместо с вызовом ПродолжитьВызов() в той точке, где типовая логика всё же должна выполниться; и только когда метод нужно именно переписать целиком — полная подмена без ПродолжитьВызов(), с комментарием, зачем и какую версию типового кода она повторяет.

Правило 3. Каждый захваченный объект — это обязательство

Захват объекта в расширение выглядит бесплатным: щёлкнул — и форма твоя. На деле каждый захваченный объект — это договор: «при каждом обновлении типовой я перепроверю, что моя версия совместима с новой». Когда расширений с десяток, а в каждом по несколько десятков захватов, этот договор разрастается до сотен пунктов, о большинстве которых никто не помнит. Поэтому: захватывать минимум, на уровне формы предпочитать программную доработку в обработчике ПриСозданииНаСервере расширения, а список захваченного периодически ревизовать — дерево конфигурации расширения в конфигураторе и есть этот список: всё заимствованное из типовой в нём на виду.

В разборах проектов, где расширения стали источником проблем — а именно такие приходят в редакцию, — картина одна и та же: хаос начинается не с плохого кода, а с расширения «Доработки2», созданного потому, что про первое уже никто не помнил, что там лежит.

Правило 4. Применимость проверяется до обновления, а не после жалоб

Расширение, которое не смогло примениться, как правило, не роняет базу — оно отключается, а пользователи молча теряют функциональность и узнают об этом раньше вас; в отдельных сценариях (подписки на события, серверный кеш) последствия бывают заметнее — тем важнее репетиция. Поэтому обновление типовой репетируется на копии: накатили обновление, проверили в конфигураторе состояние каждого расширения, прошлись по журналу регистрации с отбором по уровню «Ошибка» за время после обновления — сбои применения расширений платформа пишет туда. И только после чистой репетиции — прод. Безопасный режим и профили безопасности для расширений из недоверенных источников — отдельная тема, но правило то же: расширение стороннего автора не подключается в прод без прогона на копии. Исключение одно — экстренный патч вендора по критической ошибке: прогон ужимается по времени, но не отменяется.

Итог

Расширения не отменили цену доработок — они её отсрочили и сделали управляемой. Платить всё равно придётся: при каждом обновлении типовой, за каждый захваченный объект и каждый &Вместо. Дисциплина из четырёх правил держит эту цену предсказуемой. Без неё расширения честно воспроизводят тот же хаос, от которого когда-то спасали, — только теперь он называется современно.