Хаос в Расширениях 1с

Типовую конфигурацию можно не снимать с поддержки. Изменения можно вынести отдельно. Обновления проходят спокойнее. Разработчик не лезет напрямую в конфигурацию поставщика. Руководитель доволен: “делаем аккуратно”. Пользователи довольны: “доработка появилась быстро”. Но через год-два в некоторых базах появляется другая картина: • расширений стало много, но никто не помнит, зачем каждое из них создавалось; • в одном расширении лежат и печатные формы, и изменения ролей, и перехваты форм, и служебные регистры; • часть расширений отключать страшно; • после обновления типовой конфигурации что-то ломается, но непонятно где; • новый разработчик открывает расширение и видит “маленькую вторую конфигурацию”; • владельца у расширения нет, документации нет, проверки перед релизом нет; • все знают, что “надо бы разобрать”, но пока работает — не трогаем. Так расширения из инструмента аккуратной доработки превращаются в отдельный слой хаоса. В этой статье разберем, как использовать расширения 1С без фанатизма: когда они действительно нужны, когда лучше выбрать другой способ, как вести реестр расширений, что проверять перед обновлением и какие правила помогут не превратить расширения в техдолг, который никто не хочет открывать. главная ошибка — воспринимать расширение как что-то легкое и безопасное само по себе. Мол, если не трогаем основную конфигурацию, значит всё хорошо. На практике расширение может влиять на систему очень серьезно: • изменять поведение форм; • добавлять реквизиты и команды; • расширять роли и права; • добавлять регистры, справочники, обработки, отчеты; • перехватывать обработчики; • менять логику заполнения и проверки документов; • встраиваться в бизнес-процессы и задачи; • работать с регламентными заданиями и интеграциями. То есть расширение — это не просто “внешний файлик рядом с базой”. Это часть архитектуры решения. Расширение помогает сохранить типовую конфигурацию на поддержке. Но оно не отменяет проектирование, тестирование, code review, документацию и ответственность. Почему расширения превращаются в хаос: 1. Расширение создают “на одну задачу”, а потом продолжают складывать туда всё подряд Сначала расширение появляется для небольшой правки формы. Потом туда добавляют печатную форму. Потом — команду на форме документа. Потом — общий модуль. Потом — регистр сведений для настроек. Потом — перехват заполнения. Потом — временную логику “до нормальной реализации”. Через полгода расширение называется примерно так: “Расширение_Доработки_Для_Бухгалтерии_Новое_2_Финал” А внутри лежит всё, что не успели нормально разложить. Проблема не в самом расширении. Проблема в отсутствии границ. Также у расширения должен быть владелец. Не обязательно один разработчик на всю жизнь. Но должна быть понятная ответственность: кто понимает назначение расширения, кто принимает решение о его изменении, кто проверяет его после обновления, кто может объяснить, можно ли его удалить, кто знает, какие бизнес-процессы оно затрагивает. Если владельца нет, расширение постепенно становится ничейным. А ничейные артефакты в 1С обычно живут дольше всех и ломаются в самый неудобный момент. Бывает так: конфигурацию обновили, пользовательские сценарии проверили, основные документы открыли, обмены посмотрели. А расширения — “ну они же подключены, значит работают”. Потом в рабочей базе выясняется: перехватчик формы перестал срабатывать. Расширения должны быть частью релизного чек-листа. Иначе они становятся скрытым источником риска. Чтобы расширения не превращались в хаос, не нужно сразу писать регламент. У каждого расширения должно быть назначение Расширение должно отвечать на вопрос: “Зачем оно существует?”: Контроль заполнения реквизитов договора в 1С:Документооборот, Дополнительные печатные формы для кадровых заявлений, Интеграция с внутренним сервисом проверки контрагентов, Адаптация формы заявки на оплату под внутренний процесс. Также не нужно складывать всё в одно расширение Удобно иметь одно расширение “на все доработки”. только в начале, Потом такое расширение становится слишком тяжелым: его сложно тестировать, непонятно, какой бизнес-процесс оно затрагивает, сложно оценить влияние изменений, сложно передать другому разработчику. Лучше группировать расширения по смыслу: Но и не нужно уходить и в обратную крайность: одно расширение на каждую маленькую кнопку тоже может создать лишний шум. Нужен баланс, расширение должно быть достаточно маленьким, чтобы его понимать, и достаточно цельным, чтобы им было удобно управлять.