Доработка 1С без превращения системы в монолит

Каждая доработка 1С должна быть проверена на влияние на обновления, обмены, производительность и владельцев процесса.

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

Поэтому перед любой доработкой мы делаем четыре вещи:

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

Если доработка связана с тяжёлыми расчётами, интеграциями, витринами данных, пользовательскими кабинетами или нестандартными workflow, мы рассматриваем выделенный сервис и слабую связанность через API или ESB.

Бизнес получает нужную функцию, а IT сохраняет управляемость: можно обновляться, отключать устаревшие сценарии, мониторить ошибки и развивать контур без полной переработки 1С. Так мы выводили клиентов из ситуации, когда содержать кастомную конфигурацию дороже, чем переписать её заново.

Что меняется после наведения порядка:

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