По итогам работ нам захотелось поделиться мыслями, как оптимально вносить доработки в конфигурацию, чтобы их было легче поддерживать при последующих обновлениях.
Как выглядит сложная для обновления конфигурация 1С
На этапе анализа конфигурации получился внушительный список потенциальных сложностей:
- большое количество доработанных объектов — 1911 добавленных и 1049 измененных, 246 файлов внешних отчетов и обработок;
- большое количество объектов частичного обновления;
- большое количество типовых объектов, различающихся внутренними идентификаторами (ГУИД-ами) с объектами типовой конфигурации, то есть некорректно добавленные объекты при частичном обновлении;
- наличие функционала в доработках, работоспособность которого вызывала сомнения;
- сильно доработанный механизм ЭДО + сильно изменившаяся архитектура типового ЭДО в целевой версии конфигурации «Бухгалтерия предприятия КОРП 3.0»;
- большое количество интеграций;
- доработанный механизм оповещений;
- доработанные механизмы работы с файлами;
- доработанные платежный календарь, реестр платежей модуля «БИТ.ФИНАНС»;
- доработанный механизм казначейства модуля «БИТ.ФИНАНС»;
- доработанный механизм согласования модуля «БИТ.ФИНАНС»;
- доработанный механизм бюджетирования модуля «БИТ.ФИНАНС»;
- использование внешнего кода в базе модуля «БИТ.ФИНАНС» (алгоритмы, пользовательские условия, действия, функции, запросы).
Чтобы обновить конфигурацию, перенести и протестировать доработки, пришлось анализировать более 10 пропущенных релизов типовой конфигурации «Бухгалтерия предприятия КОРП 3.0», выполнить поиск неиспользуемых объектов, выявить объекты, которые являлись копиями типовых объектов версий релизов меньше целевой версии, проанализировать механизмы ЭДО и «БИТ.ФИНАНС», доработать обработчики обновления для корректного переноса данных, написать обработку для обновления внешнего кода ИБ и т.д. и т.п.
«Смотреть в будущее при доработке конфигурации»: выводы
Проект стал показательным для направления сложных обновлений и вдохновил написать некоторые рекомендации по оптимальному внесению доработок в конфигурацию. Доработки через расширения в данном материале не рассматриваются.
Исключать частичное обновление
Не все согласятся с данным пунктом, так как полное обновление нередко бывает накладным для компании — нет ресурсов или времени.
Но, если нет возможности исключить частичного обновления, можно следовать следующим правилам:
- Правильно добавлять объекты (сохранять ГУИД-ы типовых объектов) — забирать с использованием сравнения/объединения из новой конфигурации, а не копированием.
- У добавленных объектов и при внесении кода частичного обновления в уже существующие объекты конфигурации, заполнять комментарий с форматом типа «ФИО разработчика, № задачи, взят с релиза №XYZ».
- Доработки в объектах частичного обновления также снабжать комментариями разработчика.
Это сильно упростит задачу по анализу и дальнейшему обновлению конфигурации.
Аккуратно использовать в доработках тип «ХранилищеЗначения»
Приведем пример из проекта: есть добавленный регистр сведений, который хранит какие-то настройки информационной базы. У него есть ресурс с типом «ХранилищеЗначения». В регистре есть записи, а какие данные хранятся в данном ресурсе мы не знаем. Настройки в регистре в ресурс с типом «ХранилищеЗначения» записаны в базе до обновления и с использованием архитектуры конфигурации до обновления.
После обновления в новой архитектуре конфигурации часть хранимых данных регистра потеряла работоспособность. В текущем примере настройка содержала список значений типового перечисления, которое в новой типовой конфигурации перестали использовать и переименовали с добавлением префикса «Удалить». Обработчики обновления обработали данные, в которых участвовало это перечисление. И фактически доработки рабочей конфигурации, использовавшие эту настройку, потеряли работоспособность. Точнее они работали, ошибок не выдавали, но нужный результат не достигался. В результате пришлось проверять и перезаписывать настройки данного регистра.
Не копировать типовые методы для доработок
Вносите изменения непосредственно в типовые методы. На момент внесения доработок кажется, что все логично: копируем типовой метод, его дорабатываем и вызываем вместо типового. Но в момент обновления конфигурации типовые методы модифицируются, а ваши доработанные останутся без изменений. В таком варианте доработки либо перестанут работать, либо станут отрабатывать некорректно.
Создавая объект путем копирования типового объекта, постараться сделать его максимально независимым от функционала типовой конфигурации
При обновлении функционал копии документа с большой вероятностью будет приводить к ошибкам из-за изменений типовых механизмов — проведение документов, подключаемые команды, вызовы методов общих модулей, обработка элементов форм, добавление функционала подписок и прочее.
Необходимо иметь ввиду наличие такого объекта и его обновления по аналогии с типовым.
Использовать типовой функционал заполнения данных при программном создании объектов
Часто разработчики реализуют для пользователей обработки, из которых программно создают и заполняют объекты — справочники, документы и т.д. Важно помнить, что алгоритмы метода «ОбработкаЗаполнения» модулей объектов выполняют чаще всего минимально необходимое заполнение данных объекта. Игнорирование алгоритмов данного метода часто приводит к незаполненным данным объектов, которые при интерактивной работе пользователем заполняются, а «самописное» программное заполнение их может не описывать.
Такого рода проблемы в данных начинают себя проявлять при обновлениях: ломаются обработчики обновления, некорректно обрабатываются данные и прочее. Поэтому, не стоит игнорировать метод «Заполнить()», при программном создании и заполнении объектов.
Аккуратно использовать подписки на события
Подписки на события, учитывая наш опыт обновления, очень непостоянный объект. При работе с ними важно учитывать их обособленность и независимость.
Мы столкнулись с поломкой логики работы в подписках после обновления: из-за изменений архитектуры ЭДО — данные табличной части «ДокументыОснования» документов «ЭлектронныйДокументВходящий», «ЭлектронныйДокументИсходящий» перенеслись в регистры сведений — все доработки в подписках клиента данных документов стали работать некорректно или совсем перестали работать, что потребовало детального анализа и их фактического перевнедрения.
В модуле «БИТ.ФИНАНС» пришлось переделывать логику в установке статусов объектов: если до обновления установка статуса была описана непосредственно в модуле объекта документа в методах «ПередЗаписью», «ПриЗаписи», то после обновления все ушло в подписки на события. И здесь началось самое интересное, что же отработает раньше — подписка клиентская доработка или подписка «БИТ.ФИНАНС»? Оказалось, как повезет — часть доработок перестала работать, часть стала работать некорректно, с частью повезло.
При использовании типовых объектов в доработках, использовать связанные непосредственно с ними объекты полностью, либо не использовать вообще
Говоря по-простому, если принимается решение использовать документ, а он при записи пишет информацию в регистр сведений, то необходимо провести анализ и записать корректную информацию в данный регистр, либо не писать в данный регистр совсем ничего.
Поясним, с чем это связано: при обновлении обрабатываются данные регистра. Если записей в регистре нет, то и обрабатывать будет нечего, если данные в регистре есть, то они обрабатываются по правилам обработчика обновления. Если данные в регистре есть, но они заполнены как вздумалось разработчику (по принципам «что-то заполним», «что-то не заполним», а еще может «что-то свое добавим» и будем работать только с ним), то в 100% случаев возникнут проблемы при обновлении.
Данная рекомендация обусловлена сложностью поддержания работоспособности доработок в типовых объектах при изменениях типового функционала конфигураций, который «вроде как используется», а «вроде и не используется».
В описании проекта одной из сложностей упоминался сильно доработанный клиентом механизм ЭДО и данный же механизм претерпел кардинальные изменения между версиями релизов типовых конфигураций — изменилась архитектура ЭДО:
- появилась новая сущность документ «СообщениеЭДО»,
- старые регистры, связанные с ЭДО, переименовались с добавлением префикса «Удалить» и перестали использоваться;
- добавились новые регистры сведений, связанные с ЭДО;
- алгоритмы разнеслись по новым общим модулям форматов ЭДО;
- изменился механизм получения настроек ЭДО, совершенно изменился интерфейс работы с ЭДО (формы, обработки).
В конфигурации были изменены регистры ЭДО, которые стали «Удалить». И доработаны они были по принципу «типовое не подходит, добавим свое».
Что же мы получили при обновлении: есть данные в регистрах, но они совершенно не подходят под выборку обработчиков обновления, а еще они и смысл другой хранят. Анализировать данные, придумывать как их перенести и сохранить, как по таким данным заполнить новые сущности пришлось долго и с привлечением разработчиков и аналитиков клиента. Данные перенесли, сущности создали, переписали все доработки клиента, связанные с ЭДО, на новую архитектуру. В процессе перевнедрения доработок и выяснилось, что из типового функционала ЭДО разработчики не использовали по его прямому назначению НИЧЕГО!
***
Желаем всем качественного кода и лёгких обновлений!
