Ведение доработанных типовых конфигураций без расширений

Те, кто внедряет у себя типовые конфигурации, часто сталкиваются с необходимости «доработки напильником» типового кода. В результате чего в типовой код вносятся изменения и обновления релизов происходят уже не так просто, как раньше, когда код был на 100% типовым.

Очень мало кто сейчас снимает конфигурацию с поддержки, фиксируя версию 1С на каком-либо этапе, потому что конфигурации сложные, изменений много и дешевле все же обновляться на новые релизы, чем самим писать все изменения.

С появлением расширений возникло желание вынести все изменения типового кода в одно-два расширения, для того, чтобы обновления проходили без лишних проблем.

Но не тут-то было. Дело в том, что 1С позволяет добавлять свои функции до или после вызова типовых функций, замещать типовые функции, но не позволяет менять часть функций. Приходится перетаскивать весь код функции и замещать его на новый. А функции в 1С часто занимают до 10 экранов. В итоге обновлять становится сложно.

В связи с этим можно вспомнить хорошо забытый подход, который применялся еще до расширений, а именно парсинг модулей, форм и макетов. Одну из его версий я выкладывал на инфостарте еще в 2011 году.

Однако с той поры прошло много времени и 1С позволяет вносить изменения не только в код модулей, но и в формы и в макеты путем выгрузки их в каталог.

Суть методики

В чем заключается метод, который я предлагаю? Вам не придется писать расширения.

Все изменения оформляются обычным кодом в конфигураторе. Важно отметить, что изменения должны осуществляться только кодом, никаких визуальных доработок в формах. Но такой подход стал уже де-факто для доработок типовых.

По желанию вы можете помечать свои изменения понятными для программы комментариями, но это не обязательно.

При обновлении конфигурации происходит следующее:

1. Выгружаются модули файлов конфигурации поставщика.
2. Выгружаются модули файлов текущей конфигурации.
3. Модули сравниваются, при этом изменения, если они закодированы специальными комментариями, фиксируются по правилам этих комментариев, если не закодированы, то программа сравнения определяет, где добавлен код — в начале процедуры, в конце или в середине. Для начала и конца помечает изменения вставкой в начало и конец соответственно. Для середины берет ближайший код в качестве маркера для вставки.
   Автоматически определенные правила вставки кодируются комментариями специального вида.
4. В новую конфигурацию вносятся изменения согласно полученному списку вставок. Таким образом, новая конфигурация получается автоматически.
5. Остается только обработать ошибки, когда нет подходящих процедур или сигнатур для вставки в середину кода.
6. Не мешает произвести синтаксический контроль всей конфигурации, чтобы убедиться, что вставленный код адекватно вписался в синтаксис новой конфигурации.

Примеры

Здесь программист оформил вставку комментарием, понятным программе. Он сообщил парсеру, что добавляет код в конец функции (процедуры):

Функция Типовая()
    ТиповойВызов1();
    ТиповойВызов2();
    //++ВКОНЕЦ Иванов 2020-11-12
    СобственныйВызов();
    //—
КонецФункции

Функция Типовая()
    ТиповойВызов1();
    ТиповойВызов2();
    СобственныйВызов();
КонецФункции

Здесь комментариев нет, но парсер сравнивая конфигурацию с конфигурацией поставщика понимает, что изменения касались вставки в конец функции и добавит нужный комментарий, код станет выглядеть так:

Функция Типовая()
    ТиповойВызов1();
    ТиповойВызов2();
    //++ВКОНЕЦ Парсер 2020-12-22
    СобственныйВызов();
    //—
КонецФункции

Аналогично происходит и при вставке в начало директивой ВНАЧАЛО.

А вот при вставке в середину процедуры могут быть нюансы. Они связаны с определением маркеров, на которых нужно ориентироваться программе при вставке. Желательно выбирать такие маркеры, которые с минимальной вероятностью изменятся в новых релизах.

Функция Типовая()
    ТиповойВызов1();
    Для Инд = 1 По Всего Цикл
        А = 1;
        ТиповойВызов2();
    КонецЦикла;
    //++ВСТАВКА Иванов 2020-11-10
    //А=1; * КонецЦикла;
    СобственныйВызов();
    //—
    ТиповойВызов3();
КонецФункции

Здесь программист пометил, что вставлять надо после строчки А=1 и ближайшей команды КонецЦикла. Если бы этой пометки не было, программа вставила бы код после КонецЦикла, если бы такой код был уникальным в процедуре. Но если бы циклов было несколько, она взяла бы две предыдущие строки, т.е:

Функция Типовая()
    ТиповойВызов1();
    Для Инд = 1 По Всего Цикл
        А = 1;
        ТиповойВызов2();
    КонецЦикла;
    //++ВСТАВКА Парсер 2020-12-22
    //ТиповойВызов2(); КонецЦикла;
    СобственныйВызов();
    //—
    ТиповойВызов3();
КонецФункции

Замена части типового кода осуществляется директивой ЗАМЕНИТЬ, при этом используются те же маркеры типового кода:

Функция Типовая()
    ТиповойВызов1();
    //++ЗАМЕНИТЬ Иванов 2020-11-10
    //ТиповойВызов2();
    СобственныйВызов();
    //—
КонецФункции

Понятно, что над маркерами вставки надо еще немного поработать, возможно сделать их многострочными (сейчас символы перевода строки и пробелы игнорируются).

Но подход уже рабочий и позволяет автоматизировать перенос доработок в типовой код.

По крайней мере, может быть использован на фикси в организациях, где используется доработанная типовая конфигурация.

Прелесть подхода в том, что не обязательно заставлять программиста описывать изменения. Они сами задокументируются, потом уже можно будет посмотреть, насколько корректно. Но трудоемкость обновления снизится на 80%, потому что сравнение и объединение программа будет делать сама.

Обновления макетов

На практике часто также требуется обновлять типовые макеты.

Думаю, здесь наиболее эффективный подход, когда при обновлении программа вызывает процедуру, которая ищет нужные макеты и программно их модифицирует. Если макет не находится или процедура обработки не находит нужные секции макета, выдается ошибка. Таким образом, в измененной конфигурации макеты будут уже обработанные с учетом нужных изменений.

Доработка всех модулей

В парсере 2011 года была возможность доработки всех модулей, например, во все модули форм добавить процедуру-обработчик событий или при открытии каждой формы вызывать некую глобальную процедуру, аналог подписки на события. Думаю, эту возможность можно использовать и в новом парсере.