Как всем известно, программные продукты фирмы 1С еще не достигли такого совершенства, как их маркетинг, который настолько доминирует, что сначала потребители, а потом и производитель, стали путать рекламу с документацией.
Так, например, пресс-релиз многие воспринимают буквально. Мол, действительно, начиная с платформы 8.3.15.x, появилась возможность безопасно использовать в расширениях аннотацию &ИзменениеИКонтроль. Реальность же способна разочаровать неосторожного программиста и навсегда перевести его в категорию людей, первые N лет не пользующихся новинками.
Предлагаю внести ясность.
Во-первых, никаких конструкций #Вставить, #КонецВставить, #Удалить и #КонецУдалить, упомянутых на 1c.ru, разумеется, не существует. Вместо них платформа понимает: #Вставка, #КонецВставки, #Удаление и #КонецУдаления. Это настолько очевидно, что даже щепетильная 1С считает избыточным грузить посетителей своего сайта такими детальными подробностями.
Во-вторых, если вы начнете использовать &ИзменениеИКонтроль, то придется вручную проверять возможность применения расширений. Командой "Проверка возможности применения" в конфигураторе. Без этого вы можете не узнать, что код оригинальной процедуры изменился (например, после обновления), и программа невозмутимо игнорирует непонятный теперь аналог в расширении, не отвлекая пользователей от работы занудными предупреждениями. Вы будете думать, что расширение работает, а оно молча передаст свои обязанности типовым процедурам и функциям.
В-третьих, я с подозрением отношусь к новинкам от 1С в первые несколько лет.
В итоге, сам я не нашел смелость использовать &ИзменениеИКонтроль и при этом спокойно спать. Поэтому предлагаю пользоваться вроде бы работающей аннотацией &Вместо, а контроль добавить самим.
Где-нибудь в общем модуле можно определить функцию, выполняющуюся &НаСервере:
Функция СравнениеСВерсиейКонфигурации(МестоВызова, ВерсияМодуля, ВызыватьИсключение=Истина) Экспорт
// Функция для контроля на соответствие кода в расширениях текущему релизу конфигурации.
// Подробнее: //infostart.ru/1c/articles/1454444/
ВерсияКонфигурации = Метаданные.Версия;
Если ВерсияМодуля <> ВерсияКонфигурации Тогда
Если ВызыватьИсключение Тогда
ВызватьИсключение "Версия конфигурации (" + ВерсияКонфигурации + ") отличается от версии модуля (" + ВерсияМодуля + ").
|" + МестоВызова;
КонецЕсли;
Возврат Ложь;
КонецЕсли;
Возврат Истина;
КонецФункции
А в расширениях первой строчкой в заменяющих процедурах и функциях использовать конструкцию типа:
ОбщийМодульСПроверкой.СравнениеСВерсиейКонфигурации("Текст, помогающий найти проблему", "циферки.версии.с.точками");
Например:
&Вместо(ЗаменяемаяПроцедура)
Процедура Расш_ЗаменяемаяПроцедура()
ОбщийМодульСПроверкой.СравнениеСВерсиейКонфигурации("Справоник.Номенклатура.МодульМенеджера.ЗаменяемаяПроцедура", "3.1.14.500");
// полезный код
КонецПроцедуры
Такие сигнализирующие ловушки можно расставить в критически важных местах расширения. И вписывать в них актуальный номер релиза вторым параметром каждый раз после обновления. Если где-то забыть это сделать, программа выдаст ошибку, когда попытается выполнить данные инструкции. Задав по-человечески МестоВызова, легко найдете проблемное место. Короче, после обновления игнорировать проверку замененных в расширении функций станет заметно труднее. В худшем случае о забытой процедуре вы узнаете от пользователя, но сразу! А это лучше, чем узнать об ошибке из отчетов за полугодие.
Update
С момента публикации прошла неделя. И, видимо, были высказаны все основные мнения. Спасибо за поддержку и дискуссию! Ниже в порядке убывания конструктива приведу тезисы против того, чтобы с небольшими трудозатратами добавить дополнительный контроль актуальности кода в расширениях.
1. Аннотация &ИзменениеИКонтроль работает достаточно хорошо. Нужно пользоваться ею, не забывая запускать контроль в конфигураторе.
Кто же спорит, что использование встроенных инструментов лучше, чем разработка таких же аналогов? Но на мой взгляд &ИзменениеИКонтроль работает странно. Вместо сигнализации о проблеме игнорируется код в расширении. Нужно же вызывать ошибку вместо тихой неправильной работы!
2. Функция сложна в эксплуатации, потому что требует ручного изменения второго параметра в каждом месте вызова при обновлениях.
Я все равно проверяю код, вынесенный в расширение. И необходимость указать новую версию релиза воспринимаю, как отметку, помогающую отслеживать ход выполнения процесса. Также считаю, что указание релиза в каждом отдельном месте вызова — правильный подход. Использование глобальной константы для сравнения с текущим релизом дает гораздо меньше гарантий, что важные участки были проверены. А так, проверил функцию/модуль, изменил релиз во втором параметре и знаешь, что проверял, а что — нет.
3. Плохо, что исключительная ситуация возникнет уже в процессе работы, ведь может прерваться какой-нибудь важный процесс. Да и у пользователя осадочек останется.
Принцип меньшего зла, как он есть. Определяйте сами, что выгоднее в каждом конкретном случае. В принципе, функция может отработать без исключения, вернув булево значение. Также вызов исключения можно заменить на логирование или иную не заметную пользователям сигнализацию.
4. Зачем нужна функция, если можно ставить обычный комментарий в коде, либо вообще выписать на листочек важные места, чтобы не забыть их проверить?
С этого начиналось, но в моей практике оказалось недостаточным. Если пропустить пункт на листочке или процедуру с комментарием, можно об этом и не узнать. А с этой функцией пропущенный участок станет невозможно игнорировать в процессе работы. Заменить текст в параметре вызова не труднее, чем в комментарии.
5. Если использовать тестирование функциональности, то дополнительные элементы контроля не нужны.
Странно, что тестирование противопоставляется предложенному приему. Они друг другу не мешают. Функция проверки релиза может даже помочь, если в тестирование добавить вызов помеченных участков.
6. Лишняя самописная функция — страшное зло. Нужно пользоваться только инструментами от проверенного производителя!
Как давно и успешно практикующий программист, не испытываю благоговейного трепета перед элементарным кодом. Его же можно прочитать. Данная функция: маленькая, простая, не имеющая зависимостей, вписываемая в любую архитектуру. Вообще, воспринимайте предложенный вариант, как минимальную реализацию идеи, которую можно доработать, если потребуется.
7. Возможно, фирма 1С посчитает этот код отладочным и откажется давать какой-нибудь сертификат.
Пока не спросишь — не узнаешь. У меня нет опыта в этом вопросе, но как я понял из комментариев, фирма 1С сама активно использует функции проверки версий БСП.
8. Функция ничего не гарантирует. Злоумышленник может просто изменить второй параметр, и тогда исключения не произойдет, а участок останется не проверенным!
Штош. Это многое объясняет. На всякий случай теперь в функции добавлен комментарий, чтобы "разрабу", спешащему избавиться от исключения, было проще понять, что от него требуется.
9. Я разочарован. Ожидал чего-то большего.
Добро пожаловать в клуб.
p.s.
В комментариях коллега привел ссылку на более надежные материалы о расширениях, чем в упомянутом анонсе. Если, конечно, у вас есть доступ к ИТС.
