Как залезть внутрь процедуры - обновление типовых расширениями

(0) Хм. Похоже на ИзменениеИКонтроль, но там "перетаскивать" все же придется.

(1) УТ 11.4 не догоняет ИзменениеИКонтроль по совместимости. улыбаемся и машем.

8.3.15.1869 + УТ11 в режиме совместимости 8.3.12 - &ИзменениеИКонтроль тоже работает, но что бы его заюзать надо еще постараться. Проблема пробелов и пустых строк это прям бич

(3) похоже, мы когда тестили, поймали грабли с пробелами наподобие https://forum.infostart.ru/forum9/topic227698/ и подумали на совместимость. а у вас отлично работает - прямо отлично(видно при обновлении основной конфы, нет проблем при вставке итд) или с оговорками?

(5) ИзменениеИКонтроль это уже проблема, стараемся не делать лишний раз, но "километровые" методы 1С порой вынуждают

(8) Да лучше бы они делали декомпозицию на процедуры таким образом, чтобы не возникало задачи влезать в середину.. а такое ощущение, что они специально делают так, чтобы по максимуму затруднить доработку через расширения.

(4) Мы до сих пор на 8.3.15.1830 - самый стабильный из рекомендуемых.Заюзать ИзменениеИКонтроль пока не получается.

(11) Последняя БП уже требует выше

(0) Вот именно об этом я говорю, когда речь заходит о недостатках и ограничениях применения расширений для доработок.

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

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

PS Расширения хороши для небольших доработок, которые не вмешиваются сильно в методику, логику и алгоритмы основной конфигурации. Для доработок "сбоку". Если надо что-то переписать внутри (алгоритмы расчета себестоимости, учета НДС, расчета прибыли и т.п.) лучше делать это в основной конфигурации.

это все звучит даже пафосно "оставляем вы основной конфигурации"

Надо просто взять достаточно тяжелую конфигурацию и наступить на грабли с обновлением ее через получение измененной конфы из файла cfu
Часто даже с обновлением из файла cf тоже возникают сложности...

Именно практика внедрений с граблями при обновлениям сильно нагруженных конфигураций послужила поводом к разработке механизма Расширений. Это в общем... А если еще более общим образом, то механизм этот похож и другие платформы разработок. Но мне сейчас лень слишком подробно фантазировать в этом направлении.

(17) только конфигурации выбирай не такие уж легкие. УНФ, в этом смысле, будет нижней градации тяжести обновления.

(14) >> запилить изменения через парсер (обработку модулей).

Никакой парсер не автоматизирует тебе анализ сделанных изменений.
Парсер лишь покажет - где эти изменения есть и (возможно) куда-то их воткнёт.
Но если поставщик переписал всю логику работы измененной тобою процедуры, то никакой парсер тебе не поможет. Либо ты в процессе обновления сам откроешь модули и сделаешь сравнение ДО и ПОСЛЕ изменения и оценишь совместимость изменений с твоей доработкой. Либо после обновления получишь уведомление от пользователя об ошибке, что что-то не работает или работает некорректно.
И это ещё неплохо (получить сообщение об ошибке). Потому что некоторые доработки могут отвалиться молча, когда поставщик оставил измененный тобою модуль только для совместимости, а всю работу перенёс в новый модуль. И твой код просто тупо больше не вызывается ниоткуда.
Примеров можно массу подобных привести. И доработки в расширении сильно мешают подобные проблемы вылавливать. Т.к. нет никакого инструмента для автоматического сравнения расширения с основной конфигурацией и конфигурацией поставщика, чтобы увидеть двойные изменения (объект, доработан в расширении и объект доработан в обновлении).

(20) может он изменения вносит только в события форм типа "ВалютаПриИзменении" и предопределенные методы объектов "ОбработкаПроведения"

ОбработкаПроведения никуда не денется

и

ВалютаПриИзменении -мало шансов, что переименуется

а вот эти ваши общие модули, это не для Гения, он стратегически мыслит

кстати если все срастется и будет куда вставлять свою локализацию надо все равно думать, а стоит ли ее теперь туда вставлять в таком виде? может логика стала другой при внешнем совпадении

(24) маркеры... В пробелы не умеет...

Где-то такое уже было?
Ах, да... Это же ИзменениеИКонтроль в расширении

(26)Костыли еще те.

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

(22) >> ты говоришь о 5% проблем, с которыми сталкивается обновляльщик.

Правило Парето говорит, что 80% проблем на выходе возникает как раз из-за 20% таких вот несостыковок.

Чем больше доработок ты перенёс в расширение тем выше процент будет таких неоднозначных ситуаций, не поддающихся никакому автоматизированному анализу - только глазами, руками и головой - проверять каждый доработанный объект - как он был изменён поставщиком и совместимы ли изменения со всеми расширениями. И хорошо, если расширение одно единственное. Если расширений больше двух и есть объекты, которые доработаны одновременно в нескольких из них, каждое обновление превращается в бесконечный ад, по сравнению с которым обновление по старинки (без всяких расширений) покажется манной небесной.

(31) объясни внятно, чем твое отличается от ИзменениеИКонтроль?

а я вот взял и удалил пост 33 за неуважительное отношение к программистам 1С и все. Причем, не только к ТС и совсем не к ТС, а к широкому кругу лиц, которых обозвали с какого-то перепугу неофитами.

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

(32) да походу только тем что текст процедуры или функции не контролируется. То есть Геша еще пока не нарывался на изменения типа "раньше была ссылка" а теперь "массив ссылок".
Он не понял что значит "Контроль"