При обновлении конфигурации 1С разработчики часто сталкиваются с неприятной ситуацией: стандартная функция, на которую опирались доработки, внезапно меняет свое поведение. Один из самых коварных случаев — это изменение типа возвращаемого значения. Например, функция раньше возвращала Массив, а после обновления стала возвращать Соответствие. Это приводит к ошибкам времени выполнения, которые не всегда легко отследить. В этой статье разберем, как можно подготовиться к таким изменениям и эффективно выявлять их.
Проанализируем ситуацию и рассмотрим как проактивные методы (подготовка к обновлению), так и реактивные (выявление проблем после обновления), чтобы создать надежную систему защиты от подобных сюрпризов.
Самый эффективный способ борьбы с проблемой — это ее предотвращение. Рассмотрим шаги, которые можно предпринять еще до установки нового релиза на рабочую базу. Эти методы помогут заранее выявить потенциально опасные изменения.
Анализ официальной документации
Фирма «1С» документирует изменения в своих продуктах. Хотя найти информацию об изменении типа возвращаемого значения бывает непросто, это первый и самый важный источник информации. Проанализируем, где именно искать:
releases.1c.ru публикуются списки изменений для каждой версии платформы и конфигурации. Перед обновлением внимательно изучите файл «Новое в версии». Используйте поиск по ключевым словам, связанным с функциональностью, которую вы дорабатывали.Важно также понимать систему версионирования 1С, например Р.П.З.С (Редакция.Подредакция.Версия.Сборка). Как правило, критические изменения в API, нарушающие обратную совместимость, стараются вносить при смене номера редакции (Р) или подредакции (П). Обновления версий (З) и сборок (С) реже содержат такие изменения.
Сравнение конфигураций
Стандартный механизм сравнения/объединения конфигураций — ваш главный инструмент. Перед обновлением на тестовой копии сравните старую конфигурацию поставщика с новой. Это позволит увидеть все измененные модули. Однако простого просмотра «diff» может быть недостаточно. Обращайте особое внимание на:
Новый Массив теперь используется Новый Соответствие, а в конце процедуры стоит Возврат этой переменной — это прямое указание на изменение.Для более глубокого анализа можно использовать сторонние инструменты, которые предоставляют расширенные возможности для сравнения версий кода и могут подсвечивать изменения в сигнатурах функций.
Использование статических анализаторов кода
Статический анализ — это автоматизированная проверка кода без его фактического выполнения. Существуют инструменты для 1С, которые могут анализировать ваш код на соответствие стандартам, находить потенциальные ошибки и «узкие» места. Некоторые из них можно настроить для решения нашей задачи: они могут сравнить экспортные интерфейсы двух версий конфигурации и сформировать отчет об измененных, добавленных и удаленных функциях. Это значительно автоматизирует и ускоряет поиск.
Ведение списка зависимостей
Это хорошая практика разработки. Ведите в своей внешней документации или прямо в комментариях к коду список стандартных функций, от которых зависит ваша доработка. Например:
// НашаОбработка.МодульОбъекта
// Процедура использует стандартную функцию ОбщегоНазначения.ПолучитьДанныеПоКонтрагенту()
// ВАЖНО: функция возвращает Структуру с полями "ИНН", "КПП".
Процедура ЗаполнитьРеквизиты()
Данные = ОбщегоНазначения.ПолучитьДанныеПоКонтрагенту(Объект.Контрагент);
// ... дальнейшая логика ...
КонецПроцедуры
При обновлении вы сможете целенаправленно пройтись по этому списку и проверить каждую функцию в новой версии конфигурации. Это гораздо быстрее, чем пытаться проверить все изменения подряд.
Даже при самой тщательной подготовке что-то может пойти не так. Проблемы могут проявиться уже после обновления тестовой базы. В этом случае наша задача — как можно быстрее их обнаружить и локализовать.
Автоматизированное тестирование (Unit-тесты)
Это самый надежный способ выявления подобных регрессионных ошибок. Идея заключается в написании небольших программных тестов, которые проверяют работу отдельных функций. В нашем случае можно написать тест, который вызывает интересующую нас стандартную функцию и проверяет тип возвращаемого значения.
Посмотрим на пример. Допустим, мы зависим от функции РаботаСНоменклатурой.ПолучитьОстатки(), которая раньше возвращала Массив.
// Это псевдокод теста
Процедура Тест_ПолучитьОстатки_ВозвращаетМассив()
// Подготовка: создаем тестовые данные
ТестоваяНоменклатура = Справочники.Номенклатура.НайтиПоКоду("001");
// Выполнение: вызываем проверяемую функцию
Результат = РаботаСНоменклатурой.ПолучитьОстатки(ТестоваяНоменклатура);
// Проверка: утверждаем, что результат имеет ожидаемый тип
ОжидаемыйТип = "Массив";
ФактическийТип = ТипЗнч(Результат);
Если НЕ ТипЗнч(Результат) = Тип(ОжидаемыйТип) Тогда
ВызватьИсключение("Тип возвращаемого значения функции ПолучитьОстатки изменился! Ожидался " + ОжидаемыйТип + ", получен " + ФактическийТип);
КонецЕсли;
КонецПроцедуры
После обновления конфигурации вы просто запускаете все тесты. Если этот тест «упадет», вы моментально узнаете не только о факте проблемы, но и о том, какая именно функция стала работать некорректно. Платформа «1С:Предприятие 8.3» предоставляет встроенные механизмы для автоматизированного тестирования.
Сценарное тестирование
В дополнение к unit-тестам полезно иметь набор тестов, которые эмулируют действия пользователя: открытие формы, заполнение полей, нажатие кнопок, проведение документа. Такие тесты проверяют бизнес-логику в комплексе. Они могут не указать на конкретную функцию, но покажут, какая часть функциональности перестала работать. Это поможет сузить область поиска проблемы.
Проблема изменения API стандартных функций — неизбежная часть работы с развивающимися системами. Простого способа получить готовый список всех изменений не существует, поэтому для обеспечения стабильности доработок используйте комплексный подход.
Применяя эти подходы в своей работе, вы сможете значительно снизить риски, связанные с обновлением релизов 1С, и сделать процесс поддержки доработанных конфигураций более предсказуемым и менее трудозатратным.