Вот решил переписать клиенту все его доработки в УТ через расширение. Чтобы ему проще было обновляться.
Столкнулся с тем, что если при обновлениях я переносил изменения в коде в середине процедуры, то расширениями так не сделаешь.
Нужно или целиком код процедуры перетаскивать и уже там менять, или же отказываться от этой идеи.
Может я чего-то не знаю и можно в отдельных участках процедуры вмешиваться с помощью расширения?
хочется Аспектно-Ориентированного программирования, знаете ли.

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

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

(2) неправда, у нас все отлично работает
Платформа 8.3.16
УТ в режиме совместимости 8.3.14

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

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

Да, лишние пробелы это просто ад
Правится платформой или режимом совместимости?

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

(7) не знал про такую фичу.
1С опять изобрела велосипед с квадратными колесами. Вместо того, чтобы ориентироваться на уникальные строчки, она тащит всю процедуру в ИзменениеИКонтроль. Гм, кто же им ТЗ пишет?

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

(9) на это мы не можем рассчитывать. Вот я когда-то (когда еще не было расширений) писал парсер, который обрабатывал модули, искал в них уникальные куски и вставлял после них. Неужели реанимировать это все добро? ;-)

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

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

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

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

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

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

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

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

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

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

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

(16) напишу как-нибудь пост на тему легкого обновления модифицированных конфигураций без расширений, ок.

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

(18) методика не зависит от сложности конфигурации. Ты суть метода понял?

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

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

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

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

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

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

(20) ДА, КЭП, совершенно верно. Но ты говоришь о 5% проблем, с которыми сталкивается обновляльщик. А 95% он автоматизирует. йо?

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

Короче, написал статью, наслаждайтесь: https://geniy1s.ru/vedenie-dorabotannyh-tipovyh-konfiguraczij-bez-rasshirenij/

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

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

(25) нет, подходы разные. У меня маркеры и не нужно тянуть весь текст процедуры, пусть он на здоровье себе меняется. Ты что, не отдупляешь разницы?

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

(27) продолжайте кипятить. То бишь расширять.

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

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

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

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

(30) ты забыл, о чем спич.
А спич о том, как делать доработки если они нужны.
Хочешь ручками сравнивать объединять без автоматизации - на здоровье, только оцени трудозатраты.
Хочешь расширениями с КонтрольИзменений - да не вопрос, только опять же сравни с моей методикой трудозатраты.
Вот когда ты слегка офигеешь от трудозатрат, тогда придешь к методике гуру.

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

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

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

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