Как читать чужой код? Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации

31.07.22

База данных - Обновление 1С

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

Сразу напишу вопросы, которые в статье не будут рассматриваться:

1. Разбор и отладка правил конвертации

2. Отладка фоновых заданий. 

3. Отладка асинхронных вызовов.

Здесь если начать описывать данный процесс, то получится статья о том, как они работают... А смысла писать давно описанное нет. Для меня пп. 2 и 3 это обычный код, который разбирается в других кейсах.

 

Кейс 3. Доработка типовой конфигурации.

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

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

1. Предметная область. Все типовые конфигурации довольно сильно привязаны к предметной области. Отсутствие знаний по предметной области не позволит Вам полноценно разобраться в происходящих бизнес-процессах. Как следствие, выявить все сценарии работы пользователей, подлежащие автоматизации - затруднительно. Настоятельно рекомендую начинать именно  с этого. В моей сфере (ЗУП), предметной областью является законодательство (ТК РФ, НК РФ), правила заполнения отчетности, локальные нормативные документы общества (положение об оплате труда, положение о ведении кадрового учета, положение о премировании). 

2. Архитектура решения. На этом этапе необходимо разобраться, в нужной Вам подсистеме. Вот что следует изучить:

а. Какие операции выполняются в рамках подсистемы.

б. Какая справочная информация используется. Какие особенности заполнения справочной информации.

в. Какие регистры, и как используются для обеспечения работоспособности подсистемы.

г. Какая отчетность на основании каких данных формируется.

Конечно, не для каждой задачи требуется столь глубокий анализ. Но при решении сложных задач, требующих больших доработок это необходимо.

3. Назначение объектов метаданных. Для более мелких задач можно начать с разбора конкретного документа/справочника/отчета и т.д. Для некоторых задач не имеет никакого значения, в какой подсистеме этот объект метаданных, и как подсистема функционирует. На данном этапе необходимо выяснить, на основании каких данных объект заполняется, и какие данные объект меняет. 

4. Сценарии работы. Сценарии работы - основа любой разработки! Этот пункт является основным, и пропускать его ни в коем случае нельзя! Сценарии работы следует изучить не только в месте доработки, но и в связанных объектах метаданных. Если поменять движения документа, и не разобраться, как формируются отчеты на основе измененных движений - сломаем отчет. Если по регистру заполняет другой документ - сломаем авто заполнение другого документа. Если изменения вносятся в интерфейс или печать - необходимо изучить эти механизмы до выполнения доработок. 

5. Работа интерфейса. Данный пункт является продолжением изучения сценариев работы. Выделил его в отдельный пункт, т.к. часто сталкиваюсь либо со сломанным интерфейсом, т.е. в неучтённых ситуациях появляются ошибки, либо неверно отображается форма. Либо пишут новые кнопки, которые на самом деле уже есть! В типовых конфигурациях следует учитывать наличие динамически создаваемых реквизитов, т.е. их нет на форме, они создаются программным путём. На наличие таких элементов указывает наличие пустых групп в дереве реквизитов управляемой формы (слева вверху). Например, в типовых документах встречаются пустые группы "ПодписиГруппа" для указания подписантов, или "ГруппаИсправление" для отображения универсальных команд механизма исправления, или "ГруппаДополнительныеРеквизиты" для отображения дополнительных реквизитов, указанных для конкретного документа. Аналогичные группы есть и в шапке документов. Всё это необходимо учитывать при изменении интерфейса.

6. Программный код. Изучение программного кода позволяет лучше понять каждый в отдельности сценарий работы. При прохождении отладчиком сценария можно увидеть, как именно срабатывает код, какие данные возвращают запросы, какие движения пишутся в регистры, откуда получаются данные, как работает печать и почему именно так и т.д. 

Код типовой конфигурации часто усложнён универсальными процедурами или целыми модулями. Они сложны для понимания, но зачастую программный интерфейс конфигурации следует воспринимать как ещё одну процедуру или функцию встроенного языка. Никто же из Вас не пытается вникнуть, как срабатывают функции встроенного языка. Мы просто изучаем, что у них на входе и что на выходе. Также и здесь, подробнее ниже.

Программный код типовых решений содержит сценарии для всей страны... Поэтому на данном этапе требуется локализовать место, которое Вы планируете доработать. И уже изучать более мелкий участок кода. 

Разобрав все указанные аспекты типовой конфигурации, скорей всего, у Вас получится выполнить доработку аккуратно, не сломав сценарии типовых объектов метаданных. 

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

 

Кейс 4. Обновление доработанной типовой конфигурации.

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

Миф №1. Не нужно дорабатывать типовую конфигурацию, иначе не сможем её потом обновлять. Главное - дорабатывать грамотно, соблюдать стандарты разработки, не создавать дубли типовых объектов метаданных для изменения и т.д. Если не делать глупостей в процессе разработки - обновление довольно несложный процесс.

Миф №2. Нельзя дорабатывать формы типовых объектов, будет сложно их обновить. Сильно ли Вы удивитесь, если узнаете, что перенести свои новые реквизиты на обновленную форму можно через простое действие Скопировать + Вставить. Не нужно каждый новый реквизит создавать заново! Не обязательно новые элементы на форму добавлять программно! Так Вы ещё один или несколько модулей сделаете нетиповыми. 

Миф №3. Обновить конфигурацию может только самый опытный сотрудник. Ничего подобного! Мне 15 лет назад дали в хлам переписанную Бухгалтерию 7.7 и за месяц я её обновил! На тот момент мой опыт составлял 3,5 года. Учитывая то, что начинал я в регионе, опыт был так себе! Главное не бояться и придумать какую-то систему для переноса доработок в новый релиз.

Теперь подсказки:

Подсказка №1. Неважно, сколько Вы пропустили релизов, обновлять нужно сразу на последний! Часто слышу от коллег, что при пропуске 5-10 релизов, они последовательно выполняют обновление своей конфигурации на каждый из пропущенных релизов. Ничего хуже и придумать невозможно, как выполнить одну и ту же работу 5-10 раз! Почему так делают:

-- Обработчики обновления могут неверно сработать, если запустить их сразу на все релизы... Это впору записать в очередной миф. Обработчики обновления так написаны, что выполняются последовательно, вне зависимости от количества пропущенных релизов. Сам выполнял обновление, когда не релиз поменялся, а редакция! 

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

Подсказка №2. Выполнять обновление необходимо в режиме "Показать дважды измененные объекты". Можете почитать что это за режим в деталях. Главный его плюс - экономия времени! Ведь обновить требуется только те объекты метаданных, которые и Вами были доработаны и фирма 1С изменила объект в одном из пропущенных релизов. Остальные объекты Вы можете считать уже обновлёнными!

Подсказка №3. Для обновления на новый релиз Вам необходимо создать несколько баз. Перечислю их и опишу зачем каждая:

База 1. Копия до обновления. Здесь мы можем смотреть код и состояние форм, которые были до перехода на новый релиз. Часто неудобно оценивать правильность кода через сравнение объединение объектов. 

База 2. Типовая конфигурация старый релиз. Здесь можно проверить как было в типовом релизе до доработок. Это требуется, т.к. не все разработчики понятным образом отмечают границы своих доработок.

База 3. Типовая конфигурация новый релиз. Аналогично база нужна, чтоб посмотреть как сделано в новом релизе. Рекомендуется здесь иметь демо-базу, чтоб иметь возможность тестировать новые механизмы.

База 4. Обновляемая база. Здесь всё просто - после завершения работ именно в этой базе будет новая конфигурация с выполненными ранее доработками. 

База 5. Типовая конфигурация старый релиз для сравнения. В этой базе мы запускаем сравнение/объединение с конфигурацией нового релиза. Это требуется, чтоб понять объём доработок в отдельных объектах метаданных. Иногда нужно сделать выбор, что переносить: свои доработки или доработки типового релиза. Бывает какие-то процедуры мы сильно переписали, а в типовой конфигурации всего пару строк поменяли. Соответственно проще в эту процедуру внести изменения типового релиза. Это сильно экономит время!

Пора описать подробности кейса:

Надо понимать, что здесь будет не инструкция "Как обновить нетиповую конфигурацию". Кейс с разбором запросов осознанно написан позднее, т.к. для обновления эти знания не нужны. Вопросы обновления форм здесь также не затрагиваются. Рассказ ведется как ответ на вопрос: "Как найти место, куда вставить дописанный код?"

Итак будет 3 ситуации:

1. Изменения внесли в запрос.

2. Изменения внесли в обычный код.

3. Изменен запрос схемы компоновки данных.

 

1. Перенос изменений в запросах:

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

б. Если в текущей процедуре/функции не обнаружен кусок запроса, не стоит впадать в панику. Нужно сделать следующий шаг: посмотреть, после какого кода был Ваш кусок кода? Что сейчас на этом месте? Очень часто Вы обнаружите переход в функцию общего модуля. Зайдя в неё можно легко обнаружить нужный запрос и внести в него изменения.

в. Если всё таки запрос был структурно изменен... Сначала, что значит структурно изменен?

-- Изменилась таблица, из которой данные получались. Иногда в типовой конфигурации меняют состав регистров, состав измерений регистра. Т.е. старый помечают как Удалить... А новый создаётся с другим составом измерений.

-- Запрос начал делаться в 2 этапа. Такие события происходят для оптимизации работы с использованием индексов.

В такой ситуации Вам нужно понять, что было изменено в запросе в версии до обновления:

-- Добавились условия

-- Добавились поля

-- Добавилась связь между таблицами

-- Добавилась собственно новая таблица и всё вышеперечисленное.

Очень полезно в сложных случаях через отладчик смотреть, как выглядит таблица после доработки. Вы тогда можете сравнить её с таблицей "до" и станет понятно, какие изменения внесены в запрос. 

Далее начинаете к новой архитектуре по частям применять внесённые ранее изменения. Ситуаций, когда вот совсем некуда вставить свой код, не так уж много! Если разбить код на маленькие кусочки, то каждый маленький кусочек становится вполне понятным, даже если неизвестна ни постановка, ни сценарий работы! Как видно из описания, знать это необязательно!

2. Перенос изменений в коде.

На самом деле. алгоритм вставки кусков обычного кода (не запросов) точно такой же! 

а. Ищем исходное место кода, определяем - есть куда вставить или нет? Возможно, часть кода вынесли в отдельную процедуру/функцию. Здесь искать надо прямо целую строку, которая предшествует написанному Вами коду. Если её нашли и далее код похож на то место, в которое Вы его вставили - радуемся результату.

б. Возможно написали в другом месте. Часто процедуры целиком переносят в другие общие модули. В таком случае надо поискать по названию процедуры/функции по всем текстам. Этот совет также помогает, когда Вы использовали типовой программный интерфейс и в том виде, как написано, не срабатывает.

в. Если опять плохой вариант, то пробуем следующие действия:

-- Для начала необходимо определить, где старый код реализован по-новому. Код бесследно не стирают, его оптимизируют, проводят рефакторинг, делают более универсальным и т.д. Крайне редко в типовых конфигурациях удаляют реализацию каких-то сценариев. Обычно добавляют новые.

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

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

-- Когда определили место новой реализации, пытаемся разобраться в старой реализации, что было добавлено? Как и с запросами, мы смотрим на добавленные условия, дополнительная обработка коллекций значений, какая-то дополнительная функция для обработки этой коллекции... Когда мы разложили весь код на простые составляющие, можно понять, что нужно написать в новой реализации, даже не зная сценария работы! 

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

ВАЖНО: Не нужно бояться ситуаций, когда требуется доработка с нуля. Об этом необходимо смело информировать руководителя проекта или архитектора. Наверняка эти люди попытаются ускорить обновление и найдут исполнителя на новую задачу. Если Вы тратите излишне много времени на решение нерешаемого - это негативно сказывается на сроках обновления и Вашей карме!

 

Остальные части доступны по ссылкам:

Часть 1. Общие вопросы. Доработка чужого кода. Code review.

Часть 3. Разбор и доработка запросов

Часть 4. Программный интерфейс. Исправление чужих доработок.

Добавляйте себе в избранное,  ставьте "+". Статья разрабатывалась 1,5 месяца, а опыт копился 18 лет!

 

Также напомню о своих предыдущих публикациях, в особенности про статью об архитекторе. Текст статьи полностью переработан, сглажены углы. Будет интересно, даже если уже читали. Вот ссылки:

1. Кто такой архитектор. Редакция 2!

2. Пример работы с файлами odt в клиент-серверной модели работы

3. Использование ПоказатьВопрос() в событии НачалоВыбора()

Чужой код чтение кода доработать чужой исправить оптимизация проверка помощь разработка запрос программный интерфейс

См. также

Обновление для КА 1.1, ЗУП 2.5, БУХ 2.0: НДС, ЕФС-1, Расчет страховых взносов, Мобилизация, Статистика, Электронные трудовые книжки, 2-НДФЛ, Регламентированная отчетность, Кадровый учет, Прослеживаемость импортных товаров

Зарплата Регламентированный учет и отчетность Кадровый учет Обновление 1С Платформа 1С v8.3 Сложные периодические расчеты 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Зарплата и Управление Персоналом 2.5 Бухгалтерский учет Налоговый учет Управленческий учет Акцизы ЕНВД ЕСН Земельный налог ИП, ПБОЮЛ, КФХ Налог на имущество Налог на прибыль НДС НДФЛ ФОМС, ЕФС Транспортный налог УСН ПСН (патентная система налогообложения) Платные (руб)

Обновления для конфигураций: КА 1.1; ЗУП 2.5; БУХ 2.0; КА 1.1 Комплексная автоматизация торговли алкогольной продукцией; КА 1.1 Комплексный учет сельскохозяйственного предприятия

19900 руб.

01.04.2020    140612    678    352    

232

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

Расширение для конфигураций 1С для автоматического подтверждения легальности обновления и выполнения обработчиков обновления при пакетном автоматическом обновлении большого числа баз 1С. А также сам модуль обработки по автоматическому обновлению баз.

2 стартмани

08.05.2019    24210    54    VPanin56    26    

26

Ссылочная константа содержит недопустимый ссылочный номер таблицы

Обновление 1С Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Россия Бесплатно (free)

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

19.03.2024    828    sergey.skirdin    3    

13

Скрипт для обновления базы с расширением из хранилища

Обновление 1С Платформа 1С v8.3 Бесплатно (free)

Небольшая оптимизация рабочего времени через скрипт обновления базы 1С с расширением из хранилища конфигураций.

22.01.2024    1115    ke.92@mail.ru    2    

24

Многопоточное обновление 1С: Управление холдингом

Обновление 1С 8.3.14 1С:Управление холдингом Абонемент ($m)

Что делать, если обновление базы в режиме предприятия выполняется значительно больше вашего технологического окна, даже если это окно - с вечера пятницы и до утра понедельника.

1 стартмани

10.01.2024    3177    saver77    18    

24

Не обновляется типовая конфигурация 1С через конфигуратор

Обновление 1С Платформа 1С v8.3 Россия Бесплатно (free)

Столкнулся с проблемой. Нужно было поднять до текущего релиза Розницу 2.3. Обновлял по старинке, через конфигуратор (база клиент-серверная). Указывал логин и пароль, ждал скачивания обновления и обновлял. Но после накатывания 5 релизов следующий устанавливаться не хотел, а точнее конфигуратор гордо говорил, что обновлений больше нет. Решение нашел здесь на форуме и хочу зафиксировать. Чтобы самому не забыть и передать опыт начинающим.

29.11.2023    1349    shestopalovpro    4    

7

Принудительный запуск дополнительных процедур обработки данных после обновления

Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Ручной запуск процедур обработки обработчиков после обновлений. Может быть полезно стажерам, консультантам, разработчикам, администраторам, всем, кто обновляет информационные базы.

1 стартмани

20.11.2023    599    6    IvanTerentev    0    

2
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. zqzq 23 20.09.21 10:23 Сейчас в теме
Миф №2. Нельзя дорабатывать формы типовых объектов, будет сложно их обновить. Сильно ли Вы удивитесь, если узнаете, что перенести свои новые реквизиты на обновленную форму можно через простое действие Скопировать + Вставить. Не нужно каждый новый реквизит создавать заново! Не обязательно новые элементы на форму добавлять программно! Так Вы ещё один или несколько модулей сделаете нетиповыми.
Какой-то вредный совет. Ещё не хватало с формами возиться и что-то копировать. Обновление через kdiff3 в автоматическом режиме объединит модули (в 99% случаев): https://wonderland.v8.1c.ru/blog/razvitie-sravneniya-obedineniya-moduley/?sphrase_id=228175
kser87; echo77; +2 Ответить
2. biimmap 1827 20.09.21 10:28 Сейчас в теме
(1) Лукавите однако... В этом способе обновления тоже требуются ручные действия! И если внимательно прочитаете, то плюсом является НЕ измененный модуль. Прокопировать изменения на форме не сложно и быстро! Так что на вкус и цвет все фломастеры разные)
3. zqzq 23 21.09.21 09:01 Сейчас в теме
(2) Там только ОК нажать, если не было пересечений изменений в этих конкретно строках, даже если в других строках модуля что-то менялось. Можно даже настроить, чтобы kdiff3 сам за вас нажимал ОК. И пересечение нетиповых и типовых изменений по конкретному номеру строки модуля это очень редко бывает.
4. biimmap 1827 21.09.21 09:50 Сейчас в теме
(3) опять лукавите! Там где нет изменений в типовом коде, через режим дважды измененных даже ОК нажимать не надо! А там где есть пересечения, а они как раз часто есть! В таких нужно аккуратно перенести изменения, т.е. руками) Поэтому с точки зрения переноса изменений в интерфейсе, Ваш пример никак не облегчает работу.

Со своей стороны стараюсь придерживаться принципа: чем меньше кода, тем лучше! Интерфейсный код тоже сюда попадает.
16. zqzq 23 22.09.21 14:11 Сейчас в теме
(4) Руками переносить, это если тупой 1С-ной сравниволкой пользоваться. Если прописать kdiff3 как по ссылке выше, она построчно сравнивает через 3-сторонее объединение и автоматически собирает итоговый модуль.
17. biimmap 1827 22.09.21 14:13 Сейчас в теме
(16) Ок изучу данный инструмент. Возможно он помогает... Он платный, бесплатный? Есть статья про него?
5. dm_romanov.idm 21.09.21 15:38 Сейчас в теме
Подсказка №1 работает, но в очень ограниченном диапазоне, поэтому похожа на вредный совет.
Простой пример - обновление ERP с релиза 2.2 на 2.5 просто не пройдет, даже с релиза 2.4 на 2.5 не пройдет, если взять не ту версию.

Скакать через версии желательно не меняя третью и тем более вторую цифру версии конфигурации например с релиза 2.4.13.123 до 2.4.13.257. А вот если скакануть с 2.4.12.102 до 2.4.13.257 проблем не оберетесь.
anbupro; chess762; mrChOP93; TerveRus; Revachol; +5 Ответить
6. biimmap 1827 21.09.21 15:40 Сейчас в теме
(5) у всех свой опыт... конечно ЕРП не доводилось обновлять ибо не моя область... Но вот в ЗУП много раз скакал через много релизов. проблем не видел)
9. dm_romanov.idm 21.09.21 15:47 Сейчас в теме
(6) Скачок скачку рознь.
Как минимум у вас могут остаться объекты и реквизиты с наименованием наподобе "УдалитьВашОбъект", а по максимуму один из обработчиков отработает не так как задумывалось его создателями и вы это увидите только по прошествии времени, с печальными результатами.
anbupro; chess762; cosmo2004; TimofeySin; TerveRus; Revachol; +6 Ответить
12. biimmap 1827 21.09.21 16:10 Сейчас в теме
7. dm_romanov.idm 21.09.21 15:42 Сейчас в теме
Дальше хуже
Расширения отнесены к вредоносным, динамическое создание элементов на форме тоже не приветствуется. Автоматизированные тесты даже не предполагаются.
Разворачиваем пять баз и вперед копипастом обновляем формы!

Если это не вредные советы то что?
Revachol; oleg-m; zqzq; +3 Ответить
10. biimmap 1827 21.09.21 16:02 Сейчас в теме
(7) Давай разбираться...

1. Расширения. Якобы они должны нам упростить обновление и разработку. Что в итоге: один и тот же объект/модуль может быть изменен разными разработчиками, причём изменения внесены в типовые процедуры. Увидеть ВСЕ изменения, т.е. сформировать финальный СФ на сколько я читал нет возможности?!

Сравнить готовый результат доработок с типовой конфигурацией также невозможно. НО! Всё равно необходимо выполнить обновление расширений, т.к. они дополняют типовые процедуры/функции, и в них используется программный интерфейс, который меняется со временем.

Количество времени, которое необходимо затратить на обновление расширений НЕРЕАЛЬНО БОЛЬШЕ, чем на обновление доработанной привычными способами конфигурации!

Ессно мне понятно, что сама типовая конфигурация обновляется быстро и позволяет сразу формировать отчеты, особенно при изменении регламентированных.

2. Автотесты в своей практике не использую. Мне тяжело понять, зачем тратить несколько месяцев на их разработку и внедрение, чтоб сократить процесс, который у меня занимает 2 дня.

Статья про мой опыт... Т.к. не вижу в них плюсов, собственно не могу рекомендовать другим.
При это Вы можете написать статью о том, какие у этого механизма плюсы.

3. Динамическое создание реквизитов всегда требует контроля наличия тех групп, которые в коде для них прописаны! Не секрет, что интерфейс меняется. Если мы добавляем немало реквизитов, то гораздо проще их скопипастить, чем перепрописывать. Опять же это из личного опыта.

Ваш опыт может быть другим. Ваши привычки также могут отличаться от моих. Хотите - используйте.

Теперь почему про интерфейс решил написать? Потому что неоднократно слышал от разработчиков, что обновлять измененные формы долго сложно и т.д. Это МИФ! Срок обновления не увеличивается. В моей практике он даже ниже!

4. Для чего нужны 5 баз описано в статье. Описан способ, которым я сам пользуюсь. Главное, что нужно было прочитать - это не 5 баз, а сравнение дважды измененных объектов. Это была более полезная информация. Если Вы можете другим способом определить, что где поменялось не используя дополнительных баз - отлично! Вы можете написать статью и поделиться тем способом обновления, которым Вы пользуетесь.

Описанное мною всегда приводило к качественному результату работы! В LG обновлял УПП, которое в глаза никогда не видел. За 3 недели работы 5 баз незнакомых мне обновлены. Это как пример.
13. dm_romanov.idm 22.09.21 07:29 Сейчас в теме
(10)
1. Расширения.

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

С помощью директивы "ИзменениеИКонтроль" платформа сама подскажет, что поменялось в модуле и запустит сравнение модуля конфигурации и расширения с помощью внешнего редактора (например KDiff).

У нас все доработки модулей по ERP в расширениях. Решение конфликтов обновления, если логика сильно не менялась, проводится за 15 минут.

2. Автотесты пишутся не для обновления, а для уверенности что ключевой функционал работает. Использование автотестов для тестов работоспособности ключевого функционала после обновления это небольшой бонус. Правда если функционал поменялся при обновлении, то необходимо будет доработать и тесты. Зато ничего не упустите и не пропустите ошибки в прод.

Если оно вам не надо, значит или системы не критичные, или просто не компания не доросла.

3. Легче контролировать исчезновение одной-двух групп, чем все добавленные элементы на форме.

Обновлять измененные формы "на глазок" действительно сложно и это не миф, да и не зачем.

Ваш опыт очевидно ограничен УПП и ЗУП, которые по сложности и по количеству глобальных в них изменений стоят на порядки ниже флагманских конфигураций. Если измененных форм в конфигурации много, она сильно развивается, а обновляете вы "на глазок", то 100% в прод просочится не один баг и времени вы затратите больше, чем с использованием расширений и/или динамического создания реквизитов.

4 .Способы которыми мы пользуемся при обновлении:
- типовые модули (общие, модули форм, объектов) дорабатываем в расширениях
- элементы форм для часто изменяемых форм создаем динамически (также в расширениях), для не часто изменяемых (обычно для справочников) прямо в формах расширений.
- используем автотесты для критичного функционала
- выгрузка в git расширений также помогает разобраться, что, кто, когда и зачем менял в коде и на формах
chess762; +1 Ответить
18. ivanov660 4330 23.09.21 21:48 Сейчас в теме
(13) по п.1. Навязываете свою точку зрения по обновлениям, однако, все зависит от ситуации. Расширениями удобно быстро пропатчить баги, а вот уже вести полноценную доработку - это то еще "дело вкуса". Особенно неудобно создание, отладка и доработка запросов, еще куча нюансов.
kser87; Revachol; biimmap; +3 Ответить
19. biimmap 1827 23.09.21 23:19 Сейчас в теме
(18) Вот для меня тоже расширения - это способ очень быстро фиксить ошибки не согласовывая с заказчиком новый релиз. Заказчик может и не знать о существовании ошибок. Имеется ввиду руководство может и не знать. По принципу быстро поднятое не считается упавшим)
20. dm_romanov.idm 24.09.21 11:05 Сейчас в теме
(18) Я на расширениях не настаиваю, хотя используем уже три года, полет нормальный.
Я против обновления "на глазок" руками, как автор предлагает. Сам так обновлял УПП, КА 1 несколько лет, отнимает много времени и нервов. Потом переписал постепенно на динамическое создание реквизитов и процесс ускорился в разы.

Создание и доработка запросов в расширениях - да, есть такая проблема. Решается копированием запроса в консоль запросов или просто в пустую внешнюю обработку.
С отладкой запросов какие проблемы возникают, что-то не припомню в этом месте проблем?
21. biimmap 1827 24.09.21 12:21 Сейчас в теме
(20) А я пытаюсь до Вас донести, что у меня интерфейсного кода измененного не так много) у меня в хлам переписаны сложные модуля общие или прочий объектный код.

И когда его переношу, так часто оказывается его некуда переносить) Надо частично заново дописывать.
Возможно в каждой конфигурации свои особенности и задачи...

Слышал и видел несколько раз, как команды переделывают сильно интерфейс "под требования заказчика". Сам таким не занимаюсь на проекте. В управляемых формах показываю пользователю, что он сам может двигать реквизиты... от восторга нет предела)

Да и важный момент... Вы пишете, что обновляли УПП и КА... Там ведь нет управляемых форм. И там да интерфейс обновлять адское занятие, особенно с привязками долбаться каждый раз... Но там и альтернативы нет)
8. salexdv 2327 21.09.21 15:47 Сейчас в теме
Подсказка №1. Неважно, сколько Вы пропустили релизов, обновлять нужно сразу на последний!

Что делать с реквизитами, у которых в имени сначала появилось слово "Удалить", а потом в очередном релизе они вообще приказали долго жить?
anbupro; TerveRus; +2 Ответить
11. biimmap 1827 21.09.21 16:10 Сейчас в теме
(8) Собственно это главная проблема, с которой мы сталкиваемся при обновлении. Но, как и остальные, она имеет простое решение!

Что я делаю в начале обновления: Самым первым шагом ищу объекты и реквизиты, о которых Вы написали!
Я их разбиваю на 2 группы:
1. То что просто исчезло бесследно и замены этим данным не появилось. Собственно тогда какая мне разница, что будет с данными в этом реквизите/объекте? Раньше требовалось очищать регистр от данных, чтоб сохранить конфигурацию, где он удалён. Не могу сказать, на сколько сейчас актуально это. Написал простую обработку по очистке движений - проблема решена.

2. Тут чуток сложнее. В обновляемую базу сначала поэтапно добавляю новую структуру. Сначала закидываю структуру там, где объект переименован и добавлен префикс Удалить. Сохраняю конфигурацию! Ищу в том релизе, есть ли обработчик, который переносит данные из этого объекта в другой.

Далее из последнего релиза переношу новое состояние этого регистра/объекта, чтоб сработал обработчик. Чуток попрыгать с бубном вокруг обработчика обновления, чтоб он сработал и проблема решена. Продолжаем обновление в режиме сравнения дважды измененных.

Описанные изменения структуры провожу только по тем объектам, которые требуют описанных маневров. Т.е. их я обновляю ПЕРВЫМИ!
14. dm_romanov.idm 22.09.21 07:43 Сейчас в теме
(11) Вредные советы продолжаются
Вместо траты времени на последовательное обновление релизов с гарантированным результатом, давайте будем в ручную анализировать обработчики и объекты конфигурации. А что если обработчиков больше сотни (это если, что не шутка). Вы представляете объём работы для проверки обработчиков? А объём багов после таких обновлений в проде, которые могут выплыть кстати далеко не сразу?

Остер отдыхает,
Хотя что говорить, человек вместо консоли запросов в следующем опусе предлагает пользоваться отладчиком и Экселем.
anbupro; TerveRus; EvgeniyOlxovskiy; +3 Ответить
15. biimmap 1827 22.09.21 10:23 Сейчас в теме
(14) На моём опыте одна итерация по релизу длится 2 недели, т.к. обычно много доработок. Возможно у Вас пару реквизитов перенести и всё, тогда можно поиграться с каждым релизом... Вы попробуйте на досуге пообновлять в ЗУП Менеджер расчета зарплаты. Может после такого опыта поймёте, что совет не шибко вреден.

Ну и в очередной раз повторюсь - напишите Ваш способ обновления сильно доработанных конфигураций! Будет хорошее описание, так с удовольствием вставлю ссылку на Вашу статью в свои 4 публикации.
chess762; EvgeniyOlxovskiy; +2 Ответить
22. TerveRus 18.11.21 11:11 Сейчас в теме
Подсказка №1. Неважно, сколько Вы пропустили релизов, обновлять нужно сразу на последний!

Бред полнейший, дальше читать не стал. Лень и попытка сэкономить время, тогда как счета за обновления, видимо, выставляете, как за каждое обновление? Таких хитрых деятелей видно за версту, и от ваших вредных советов тоже смердит издалека.

Или Вы думаете, что надо переносить изменения после КАЖДОГО промежуточного обновления? Достаточно обновиться до последнего последовательно и накатить подготовленный заранее крайний релиз со всеми доработками, если, допустим, надо обновить рабочую базу за ночь.
23. biimmap 1827 18.11.21 11:32 Сейчас в теме
(22) по моему, Вы даже эту фразу не прочитали! И бред написали в своём комментарии!!!

Я никогда не обновляю 10 раз на каждый релиз. Счета я не выставляю. не франчайзи. Здесь уже обсуждали выше, что есть ситуации, когда нужно выполнять обновление последовательно. Учитывая то, что у меня нет провалов в обновлениях Ваш комментарий неуместен просто!

Если Вам дают время 10 раз обновлять одно и тоже - ОК! Я всегда работаю в жёстких временных рамках. максимально обновление длилось месяц, и то ругани было на 3 этажа.

Если статью читаете в ключе: если не так как делаю я значит бред... Тогда да, не надо дальше читать! Статья для тех кто хочет пополнить свои знания. Успехов.
24. biimmap 1827 18.11.21 11:37 Сейчас в теме
(22) и самое главное: если мой подход к обновлению бред и вредные советы (при 100% выполнении всех доверенных мне обновлений) - предложите свой подход! Напишите статью на эту тему. Обсудим в ней Ваши подходы. Уверен, коллеги присоединятся к обсуждению.
25. Cyberhawk 135 13.01.22 00:28 Сейчас в теме
перенести свои новые реквизиты на обновленную форму можно через простое действие Скопировать + Вставить
Реквизиты и команды - да, так перенести получится.
Вот только при копировании связанных с ними элементов формы (полями ввода / кнопками) с весьма большой вероятностью произойдет перемешивание путей к данным: та кнопка, что в форме-источнике "ссылалась" на одну команду, в форму-приемник вставится уже ссылающаяся на другую команду.
26. biimmap 1827 13.01.22 10:22 Сейчас в теме
(25) Честно говоря не знакомый мне сценарий. не очень понятен алгоритм появления такой ошибки. Можете описать?

Ну и также могу сказать, когда добавляют новые элементы кодом, их определяют в какую-то группу. Так вот группу могут переименовать, переместить, или добавить в неё столько реквизитов, что добавленный реквизит становится "не пришей кобыле хвост".
27. Cyberhawk 135 13.01.22 10:48 Сейчас в теме
(26)
не очень понятен алгоритм появления такой ошибки
1. Взять демку БСП.
2. Создать новую пустую форму элемента для справочника "Демо: Номенклатура".
3. Выделить и скопировать в буфер все имеющиеся команды исходной формы элемента (в демке БСП 3.1.2 у меня там две команды).
4. Вставить из буфера их в новую (только что созданную пустую) форму.
5. Скопировать в буфер связанный с первой командой элемент (кнопку) исходной формы.
6. При вставке в новую форму кнопка будет связана не с первой командой, а со второй.

С полями ввода вставка вообще происходит с очисткой пути к данным.

Так что простота легкого переноса реквизитов / команд формы через буфер разбивается, если эти реквизиты представлены элементами формы (полями ввода) и если их тоже нужно переносить.
28. biimmap 1827 13.01.22 11:32 Сейчас в теме
Понятно о чём вы, но к обновлению это не имеет никакого отношения! Если копируешь из той же формы, просто открытой в другом конфигураторе пути не теряются! Ни для команд, ни для полей ввода.
29. kotlovD 87 22.07.22 15:38 Сейчас в теме
Подсказка №1. Неважно, сколько Вы пропустили релизов, обновлять нужно сразу на последний!
Моделирую ситуацию: пропущено 2 релиза. Есть какой то объект с Реквизит1. В первом релизе добавляют новый Реквизит1, а старому ставят префикс удалить - удалитьРеквизит1. В обработчике обновления происходит перенос данных из удалитьРеквизит1 в новый Реквизит1. Во втором релизе происходит удаление реквизита удалитьРеквизит1.

Если вы сразу накатите второй релиз, то в итоге обработчик обновления не перекинет данные в новый реквизит и по итогу вы получите объект с пустым Ревизит1 во всех ссылках, т.е. потеряете данные
30. biimmap 1827 22.07.22 21:47 Сейчас в теме
(29) да абсолютно верно, поэтому я сначала структурно обновляю описанную Вами ситуацию, а потом одним махом обновляю всё остальное. Если не ошибаюсь, то об этом в статье написано.

Просто многие коллеги из-за наличия проблем с одним реквизитом по нескольку раз обновляют всю конфигурацию! Представьте сколько ненужной работы выполняется!
31. kotlovD 87 23.07.22 09:47 Сейчас в теме
(30) Ясно. значит не вчитался. Само собой. скрупулезно обновлять промежуточные релизы нет никакой необходимости, единственная задача сохранить свои доработки по метаданным
Оставьте свое сообщение