Перед тем как приступить к масштабному обновлению конфигурации 1С (например, при перескоке через 10 и более релизов), критически важно провести аудит текущего состояния системы. Нам необходимо четко понимать, какие объекты были изменены программистами, а какие остались типовыми. В этой статье мы разберем стандартные и профессиональные методы выявления различий, которые помогут избежать потери уникального функционала при обновлении.
Начнем с самого простого и надежного способа, который встроен в платформу 1С. Для того чтобы увидеть все правки, внесенные в систему относительно типового решения, мы должны сравнить Основную конфигурацию с Конфигурацией поставщика. Рассмотрим, как это сделать по шагам:
Конфигурация — Сравнить конфигурации....Важный момент: Если конфигурация находится на поддержке, именно сравнение с конфигурацией поставщика покажет все отклонения от «эталона», который заложил разработчик (например, фирма 1С).
После завершения процесса сравнения перед нами откроется дерево метаданных. Объекты, в которых есть различия, будут отмечены специальными значками. Однако часто возникает ситуация, когда мы видим, что ОбщийМодуль или модуль объекта изменен, но не понимаем, что именно там написано. Разберем, как проанализировать код:
Проанализируем ситуацию: если вы видите различающийся модуль, простого двойного клика может быть недостаточно. Чтобы увидеть детальную разницу в текстах, выполним следующие действия:
Когда мы имеем дело с большим количеством изменений, ручной перебор каждого объекта становится неэффективным. Рассмотрим способы оптимизации этого процесса:
Использование фильтров в окне сравнения. В окне сравнения и объединения обязательно обратим внимание на командную панель. Мы можем установить режим «Показывать только различия». Это позволит мгновенно отсечь сотни типовых объектов, которые не подвергались правкам, и сосредоточиться только на доработках.
Формирование отчета о сравнении. Если нам нужно согласовать список изменений с заказчиком или использовать его как чек-лист, мы можем сформировать текстовый или HTML-отчет. Для этого в меню «Действия» окна сравнения выберем пункт «Отчет о сравнении». В настройках отчета рекомендуем включить детализацию до свойств и строк кода. Такой документ удобно просматривать в браузере или текстовом редакторе, не заходя в конфигуратор.
Иногда система помечает объект как измененный, хотя фактически код в нем идентичен типовому. Выясним причину такого поведения. Это может происходить из-за:
Чтобы очистить список изменений от такого «мусора», мы можем применить правило «Взять из конфигурации поставщика» для тех объектов, которые мы точно не планировали менять. Это «причешет» конфигурацию и упростит дальнейшее обновление.
Если стандартный механизм кажется недостаточно наглядным, разберем более продвинутые подходы:
Использование 1C:EDT (Enterprise Development Tool). Это современная среда разработки на базе Eclipse. Она обладает мощными инструментами сравнения, которые позволяют видеть структуру изменений гораздо глубже. В EDT реализована поддержка Git, что дает возможность сравнивать не просто две версии, а отслеживать всю историю изменений по коммитам.
Внешние Diff-инструменты. Профессиональные разработчики иногда выгружают модули в текстовые файлы и используют программы типа Beyond Compare или KDiff3. Они позволяют более комфортно работать с большими объемами кода и имеют продвинутые алгоритмы сопоставления строк.
Напоследок проверим важный технический аспект. Перейдем в меню Конфигурация — Поддержка — Настройка поддержки. Здесь мы увидим статус каждого объекта. Если объект имеет статус «Объект поставщика редактируется с сохранением поддержки», он обязательно будет фигурировать в отчетах об изменениях. Если вы обнаружили, что объект помечен как измененный, но код в нем чист — возможно, стоит вернуть ему статус «Объект поставщика не редактируется», чтобы облегчить жизнь системе при следующем обновлении.
Таким образом, комбинируя стандартное сравнение, отчеты и внимательный анализ модулей через контекстное меню, мы получаем полную картину доработок, что гарантирует безопасность проведения процедуры обновления даже через 10 релизов.