Как выжить, если у тебя в базе 1С 50+ расширений

16.05.22

Разработка - Рефакторинг и качество кода

Расширения – это простой способ делать доработки на лету. Но администрировать большое количество расширений и не допустить бардак – очень сложно. О том, как выжить в такой ситуации, реализовать управление доработками и установкой актуальных версий расширений, на митапе «Путь к идеальному коду» рассказал Юрий Былинкин – архитектор 1С в компании Аскона.

Меня зовут Юрий Былинкин, я работаю архитектором 1С в компании Аскона.

Компания Аскона – это не только магазины, которые есть в каждом торговом центре, но и огромное производство. Я работаю в подразделении, которое обслуживает производство.

 

 

Не так давно мы перешли с УПП на ERP и нам пришлось значительно дорабатывать функциональность конфигурации. Было много задач, которые, помимо наших программистов, выполняли различные подрядчики, их было очень много.

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

 

Расширения – преимущества и недостатки

 

 

Расширения – это вообще хорошо, это все знают. Я до сих пор остаюсь фанатом расширений.

  • Любое действие первоначально нужно реализовать в расширении, потому что это просто – элементарно, обновление расширения занимает доли секунды, а конфигурация, особенно такая большая как ERP, обновляется существенное время.

  • Когда мы дорабатываем расширение, мы просто кидаем файл аналитику или пользователю (в зависимости от того, кто тестирует). Он устанавливает расширение в режиме 1С:Предприятие, перезаходит и все, можно тестировать.

  • На продуктиве разворачивать расширение тоже очень просто – никаких сравнений, объединений не требуется. Все очень быстро.

  • Расширения просто администрировать – в пользовательском режиме ERP есть интерфейс для работы с расширениями, в котором их можно устанавливать, удалять, обновлять.

 

 

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

Я тут перечисляю некоторые недостатки:

  • Многие программисты любят перехватывать процедуры с помощью инструкции &Вместо, а потом при обновлении релиза выясняется, что это изменение затерло что-то очень важное, что было в обновлении.

  • Альтернатива инструкции &Вместо – инструкция &ИзменениеИКонтроль. Ее использовать тоже не очень хорошо, потому что &ИзменениеИКонтроль нужно контролировать.

  • Еще один недостаток – отсутствие инструкций препроцессора при захвате процедур и функций.

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

Давайте рассмотрим подробно.

 

&Вместо – зло

 

 

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

Мы пытались с этим бороться следующим образом: на этапе подготовки к релизу просматривали все заимствования «Вместо» и анализировали, правильно ли это, нужно ли это заимствование вообще. Но это увеличивало время подготовки обновления, и в конце концов мы от этого отказались. Мы просто решили, что инструкцию &Вместо мы не будем использовать.

Мы используем плагин для SonarQube от компании «Серебряная пуля» и просто добавили в него свое правило, которое выдает предупреждение, если кто-то в расширении использует инструкцию &Вместо.

Чуть позже мы это правило доработали: поняли, что наиболее частый вариант использования &Вместо – это когда мы проверяем параметры, переданные в процедуру или функцию, и в случае наличия там нужных нам параметров делаем свой вызов. А если это не случается, мы просто делаем «ПродолжитьВызов()».

На экране показано, как мы модифицировали правило. В плагине для SonarQube от «Серебряной пули» есть возможность использовать свои правила проверки, написанные на языке XPath. Пришлось его немного изучить, но результат того стоил. Сейчас если кто-то использует &Вместо и не добавляет в код ПродолжитьВызов() – ему приходит замечание.

 

&ИзменениеИКонтроль – как контролировать, если текст модуля изменился

 

 

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

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

Мы АПК используем только для выполнения проверок и передачи результата.

 

Отсутствие инструкций препроцессора при захвате процедур

 

 

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

#Если Сервер ИЛИ ТолстыйКлиентОбычноеПриложение ИЛИ ВнешнееСоединение Тогда

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

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

Как мы это решили?

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

 

Сложное администрирование большого количества расширений – бардак

 

 

Почему вообще возникла проблема большого количества расширений?

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

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

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

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

Что мы сделали?

  • Мы запустили проект объединения расширений с одинаковой функциональностью – для удобства отказались от возможности давать подрядчикам работать в своих расширениях. Если возникает задача, которую должен кто-то решить, мы передаем подрядчику последний вариант этого расширения, и он над ним работает. У нас все расширения хранятся в справочнике «Файлы» программы СППР – «Система проектирования прикладных решений» от фирмы «1С». Там включено версионирование. В справочнике «Файлы» от СППР есть очень удобная фишка – когда человек редактирует файл, он его захватывает. У нас реализовано таким образом, что файлы расширений, над которыми в данный момент ведется работа, захвачены.

  • Дальше – мы опять же написали отчет, показывающий, файлы каких расширений сейчас захвачены.

  • Теперь, если кому-то нужно что-то доработать, то получается, что архитекторы участвуют в процессе разработки не только в стадии постановки и приема задачи, но и еще в серединке, когда решается, какие объекты нужно менять, мы согласовываем по списку этих объектов, какое же расширение нужно затрагивать. В перспективе тут участие человека вообще не нужно – можно запрашивать данные из той же самой СППР.

 

Следующая проблема – разворачивание расширений на продуктиве

 

 

Каждый день мы выпускаем наши внутренние релизы, которые состоят из 2-3-4-6 измененных расширений – у нас очень активно ведется разработка.

  • Раньше у нас были прописанные, утвержденные всеми регламенты разворачивания этих расширений, но они были неудобны и по факту не соблюдались. Регламент был такой: после приема работ аналитик пишет письмо архитектору с просьбой установить расширение в рабочую базу. Но такие письма писали не все и не всегда, и иногда архитекторы теряли эти письма – когда таких писем получается много, с этим действительно тяжело работать.

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

  • В итоге мы немного доработали СППР. Теперь у нас расширения хранятся в справочнике СППР «Файлы» с историей версий. Кроме этого, мы добавили в СППР несколько регистров и возможность запрашивать установку расширения – на слайде видно, что можно запрашивать установку конкретной версии или просто последней версии.

 

 

На верхней картинке карточка файла с расширением.

На нижней картинке – рабочее место архитектора, из которого он видит те расширения, которые нужно установить.

Еще мы автоматизировали саму установку расширений. Зачем это делать вручную?

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

На верхней картинке видно, что у нас есть HTTP-сервис, который позволяет получать данные об установленных расширениях. Прямо в карточке расширения видно, какие версии сейчас установлены в каких базах.

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

 

Актуальность расширений на продуктиве и в базах разработчиков

 

 

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

Мы, опять же, это решили тем же самым HTTP-сервисом.

 

 

С его помощью мы получаем отчет, который показывает:

  • какие расширения у нас в данный момент в СППР в разработке;

  • какие расширения установлены;

  • может быть, в какой-то базе вообще нет расширения – такое тоже допустимо.

 

 

Дальше – актуальность расширений в базах разработчиков. Это тоже была очень большая проблема.

Так как разработчиков много, часто возникала ситуация, что разработчик вчера работал с расширением, а сегодня по нему прилетела очередная задача, и разработчик просто брал и дорабатывал то расширение, которое находится в его тестовой базе.

Но нет, оказывается, ночью с этим расширением работал еще кто-то, и в СППР уже лежит новая версия.

 

 

Мы сделали для разработчиков сервисную обработку, которая в режиме 1С:Предприятие показывает актуальные расширения в рабочих базах и в СППР. С помощью этой же обработки можно скачать из СППР актуальное расширение и установить его к себе.

 

Итоги

 

 

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

Я только верил, что нас спасет объединение расширений, что надо тупо волевым усилием сделать, чтобы их было меньше, и, наверное, все будет хорошо.

В итоге мы не только уменьшили количество, но и реализовали полезные фишки. На них мы затратили совсем немного времени – HTTP-сервис и обработки, с помощью которых СППР работает с расширениями ERP, мы разрабатывали меньше недели.

  • Зато теперь мы значительно упростили себе жизнь – установка расширения для обновления нашего внутреннего релиза занимает пару минут, это очень легко и просто.

  • Аналитикам и программистам мы тоже помогли, потому что у них всегда есть понятная картина – достаточно запросить установку расширения, и его установят. А если не установят, сразу видно, что оно еще не установлено.

  • В целом, уменьшился бардак.

  • И эти все мероприятия в итоге привели к тому, что количество программных и технических ошибок, связанных с расширениями, у нас уменьшилось.

И неудач – наверное, только одно.

  • Проект объединения расширений нарушил принцип «Работает – не трогай!» и разработчики, которые занимались объединением расширений, столкнулись с тем, что причиной любой ошибки в программе все автоматически считали некорректный перенос кода из расширения в расширение. Хотя там ошибиться очень сложно, и всегда причинами ошибок были другие вещи.

 

 

Если эта тема окажется интересной, я планирую опубликовать на Инфостарте

  • отчет для поиска ошибок отсутствия инструкций препроцессора;

  • отчет по составу метаданных в расширениях, который нам помог понять, что где разрабатывать;

  • HTTP-сервис для работы с расширениями и клиент для этого сервиса

 

Вопросы

 

Используете ли хранилище для разработки расширений? Из контекста доклада это было не очень понятно.

Так исторически сложилось, что мы начинали с релиза, который не поддерживал хранилище расширений. И до сих пор мы не используем хранилище, хотя думали об этом. В любом случае, количество расширений у нас в рабочих базах будет 20-25, потому что они разделены по функциональности. Это означает, что разработчик, если они у него все подключены, должен будет 25 раз подключаться к хранилищу при запуске конфигуратора. Я лично пробовал работать с хранилищем расширений, мне не понравилось – именно из-за того, что нужно подключаться. А одно расширение – это опасно. Если кто-то накосячит, а мы это пропустим, расширение не будет работать – это плохо.

А почему не Git?

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

У нас Git используется только для выгрузки изменений в исходный код и для анализа его в SonarQube. Классического использования Git у нас нет. У меня только в одной команде разработчики пробовали использовать ветки Git и собирать релиз из исходного кода в Git, а не напрямую в 1С. Почему-то люди пока еще не видят преимуществ этого подхода, а заставлять их я не хочу. И так хорошо.

Как разделяете, что дорабатывать в расширении, а что – в конфигурации? Как обновляете расширение при обновлении конфигурации – например, когда нужно обновить формы?

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

Вы добавляете метаданные в основную конфигурацию или в расширение?

Мы добавляем метаданные исключительно в основную конфигурацию. Наша система репликации не позволяет работать с метаданными, добавленными в расширение. У нас используется система репликации от компании SoftPoint. Наверное, как и другие, она работает на таблицах SQL, и если мы добавим метаданные в расширение, и в одной из реплицированных баз оно применится, а в других по какой-то причине – нет (забыли установить или что-то сломалось), то новые таблицы, связанные с этими метаданными, появятся только в одной базе, и репликация встанет.

А как тестируете? Только ручное тестирование или есть автоматизация?

Автоматизация тестирования у нас в планах – собираемся использовать Vanessa Automation, но пока еще не начали.

Вы говорили про &ИзменениеИКонтроль, что проверяете наличие ошибок по журналу регистрации. А почему не запускаете автоматическую проверку применимости расширений в конфигураторе?

Действительно, вы правы, это можно автоматизировать.

В какое количество баз у вас вносятся расширения? Что вы можете предложить, чтобы транслировать расширения в РИБ – как это организовано у вас?

У нас 4 базы, которые находятся в общем контуре. Все эти базы доступны в одной и той же сети. Эти базы одинаковые, но они независимые. И у нас есть HTTP-сервис, которому мы даем команду поместить расширение в базу №1, в базу №2, в базу №3 и в базу №4.

У нас с помощью репликации подразумевается, что эти базы должны быть одинаковыми.

Зачем 50+ расширений? Я так и не понял.

Я тоже не понял, но так получилось. Так сложилось исторически, потому что расширения – это простой способ делать доработки на лету. Сейчас мы некоторые расширения объединили и у нас стало около 20 расширений. А раньше было расширение «Продажи» от нас и от подрядчиков, расширение «Закупки» от нас и от подрядчиков, два расширения «Зарплата» и т.д. За счет этого получалось так много лишних расширений.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Путь к идеальному коду".

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Когда понадобился новый оператор

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1160    ZhokhovM    2    

4

Когда разработчик платформы не добавил проверку препроцессоров

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    2690    ZhokhovM    4    

9

Реструктуризация - бесконечная история

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1910    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

27.09.2023    6970    Lemmonbri    136    

36

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

19.09.2023    4350    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9589    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Задачу эту дают на собеседованиях, видимо, те франчи, которые не в состоянии оценить человека по резюме и в ходе беседы. По идее задачи, подобные этой, должны давать начинающим студентам. Но дают всем подряд. Итак: мои 5 копеек. Критика приветствуется.

11.07.2023    2214    magic1s    32    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. tuxik07 16.05.22 18:10 Сейчас в теме
спасибо, доклад - огонь! у самих в базе КА 2.4 30 расширений и 171 элемент в справочнике Дополнительные отчеты и обработки, предстоит переход на 2.5.
artspeed; ardn; +2 Ответить
2. aximo 2027 17.05.22 09:35 Сейчас в теме
"Я тоже не понял, но так получилось" - хороший аргумент от "архитектора" 1с компании....
Dentaky; autosvg; Brawler; itoptimum; +4 Ответить
7. ardn 622 17.05.22 09:59 Сейчас в теме
(2)
аргумент от "архитектора"

Наверное из доклада не понятно, такая штука досталась мне в наследство
9. aximo 2027 17.05.22 10:13 Сейчас в теме
(7) Наоборот, я из доклада понял, что это под вашим руководством создавалось "Не так давно мы перешли с УПП на ERP и нам пришлось значительно дорабатывать функциональность конфигурации. Было много задач, которые, помимо наших программистов, выполняли различные подрядчики, их было очень много."
10. ardn 622 17.05.22 10:18 Сейчас в теме
(9) В данном случае МЫ - это организация.
Странно было бы сначала добавлять проблемы, чтобы потом их мучительно разрешать.
12. s22 19 17.05.22 11:54 Сейчас в теме
(10)
Странно было бы сначала добавлять проблемы, чтобы потом их мучительно разрешать.


Ведь кто то принимал решение внедрять УПП?
3. s22 19 17.05.22 09:41 Сейчас в теме
Предлагал 1с добавить кроме изменитьиконтроль добавить областьизменитьиконтроль. В функциях уже есть области и при изменить и контроль перетаскивается вся функция и проверяется ВСЯ.

Если использовать области, а они уже зачастую разбивают функции в типовых, то размер области изменения уменьшится
itoptimum; +1 Ответить
4. John_d 5277 17.05.22 09:47 Сейчас в теме
Сейчас 54, через 5 лет 250, через 10 лет 500.
Может лучше после успешного тестирования маленького расширения, объединять все расширения в одно большое.
Brawler; maksa2005; ivnik; ardn; ivanov660; +5 Ответить
6. ivanov660 4330 17.05.22 09:52 Сейчас в теме
(4)На сколько я помню, то больше трех расширений на одни метаданные не сделать, т.ч. процесс "схлопывания" должен быть.
А из этого последует - расширенная конфигурация (в расширении).
8. ardn 622 17.05.22 10:00 Сейчас в теме
(6) надо поставить эксперимент
5. s22 19 17.05.22 09:47 Сейчас в теме
для расширений надо добавить папки, так было бы удобнее
13. cdiamond 233 17.05.22 11:59 Сейчас в теме
(5) и чтоб с иерархией, расширение расширений ))
11. sapervodichka 6697 17.05.22 11:06 Сейчас в теме
По расширениям у меня такое мнение - это очень хороший инструмент:
- В расширения запихиваю автономные решения, не зависящие от изменений релизов основной конфы.
- Имею отдельный префикс для объектов и методов каждого расширения.
- А что-то завязанное на конфу делаю в конфе с динамическим выводом на формы и переопределением событий.
user811769; gmw; myoker; json; ivnik; erutan; ardn; +7 Ответить
14. quazare 3586 17.05.22 12:19 Сейчас в теме
(11) молодец! краткость - сестра таланта!
sapervodichka; +1 2 Ответить
26. sapervodichka 6697 19.05.22 11:53 Сейчас в теме
(14) осторожно, у тебя уже хейтеры появились )))
15. vld1973 85 17.05.22 16:19 Сейчас в теме
Спасибо, вы проделали колоссальную работу. Самому предстоит переход на КА25, уже начал "склеивать" лишние расширения, чтобы переход стал возможен в разумные сроки.
16. user1647001 17.05.22 16:34 Сейчас в теме
Юра, Юра... 50 расширений.. а разработчиков сколько - тоже 50?)
привет с завода)))
17. Brawler 454 17.05.22 21:39 Сейчас в теме
Скажу так, в ноябре 2021 годя мне досталась база ERP 2.4.13 с 40+ расширений, ну и обработок/отчетов внешних под 300 штук
На сегодняшний день еще живы порядка 180 обработок/отчетов внешних.
Расширений осталось грубо говоря 3 штуки: Основное расширение, Интеграция с ДО, Затычки (исправление косяков 1С)
Да есть и несколько других расширений, но они сервисные, для программистов, а не юзверей.

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

И ваще красота когда расширение подключено к хранилищу конфигураций!!!
Dentaky; John_d; ardn; +3 Ответить
18. user662404_itlexusss 28 18.05.22 07:43 Сейчас в теме
Как вы выполняете отладку этого чуда? Не предскажешь какое расширение накрывает код, который видишь в модуле. Причём одно из расширений может кардинально перестроить результат. Мы даже среди десятка расширений начали теряться и в конце концов перешли на git+edt
TimurD; ardn; +2 Ответить
29. ardn 622 19.05.22 14:04 Сейчас в теме
(18) Да, в этом то и проблема
19. stein13 9 18.05.22 08:09 Сейчас в теме
Мы на проектах, как правило работаем с одним большим расширением. Причем работают несколько программистов одновременно средствами Хранилища.
Правда иногда возникает вопрос, есть ли смысл добавлять в расширения печатные формы, отчеты или лучше их сделать внешними? Как вы делаете, коллеги?
NeLenin; Brawler; +2 Ответить
21. s22 19 18.05.22 11:10 Сейчас в теме
(19)
Правда иногда возникает вопрос, есть ли смысл добавлять в расширения печатные формы, отчеты или лучше их сделать внешними? Как вы делаете, коллеги?


Справочники, реквизиты и т д добавленные в раширения не получится удобно использовать при разработки отчетов
mikl79; Brawler; +2 Ответить
22. ardn 622 18.05.22 11:29 Сейчас в теме
(19)
лучше их сделать
Говорят, и производительность обработок и отчетов в расширениях выше, чем во внешних.
Лучше конечно все делать в расширении. Но внешние обработки используются и будут использоваться, потому что их гораздо проще разрабатывать (создал обработку, кинул в модуль служебный текст, и рисуешь форму или отчет ваяешь), контекст конфигурации доступен в полной мере (а в расширении у тебя есть только контекст расширения), и самое главное - простота деплоя. Изменение расширения вызывает сообщение о перезапуске, а обработки ты можешь менять на лету.
23. Brawler 454 18.05.22 23:18 Сейчас в теме
(19) Мы все стараемся добавлять именно в одно расширение.
Реально проще потом искать, где какая функция применяется в наших разработка, и прочее.
И так как используем хранилище конфигурации, то есть и история кто что менял и когда.
Легко сдавать изменения в хранилище и потом легко их оттуда брать в рабочей базе чтобы применить.
Нет тупой возни с обработками, сохрани, измени, верни назад... засираются папки с этими обработками, начинаешь путаться...

Переход с 2.4.13 на 2.5.7 принес страдания, база новая для моей команды, наследство убогое, 300 обработок/отчетов, 40 расширений. Банально даже для теста накатывали 2.5.7, и сразу напрочь отваливались 20 расширений, обработки тоже массово умерли, во всем этом хозяйстве искать все проблемы это было еще то удовольствие, за 2.5 месяца вытянуть тока удалось. Сейчас рефакторинг и еще раз рефакторинг.

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

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

Нужно быть сумасшедшим чтобы так много расширений в базе держать.

Внешние обработки/отчеты хороши при отладке в самом начале разработки отчета/обработки (медленно стартует ERP чтобы сразу все в расширении делать, хотя все от ситуации конечно), но потом все равно в расширение тянешь
20. Azamatex 12 18.05.22 10:22 Сейчас в теме
При обновлении конфигурации "ИзменениеИКонтроль" помогает увидеть какие процедуры изменились поставщиков, поэтому это удобно. Нажимаете Проверить возможность применения, и видите сразу все ошибки (не нужно ждать когда у пользователей выйдет ошибка).
"Вместо" я использую только совместно с "ПродолжитьВызов", тоже удобно, например пишите свое условие, если проходит, то продолжить вызов.
gmw; kote; Brawler; triviumfan; +4 Ответить
24. Brawler 454 18.05.22 23:20 Сейчас в теме
(20) то как 1С пишет платформу даже ИзменениеИКонтрольне спасает порой)) еще недавно приходилось в куче мест ИзменениеИКонтрольменять на Вместо, так как платформа ошибочно думала что есть изменения в коде, но их не было... уже починили конечно это, но осадочек остался)) когда сломают в следующий раз?
monkbest; ardn; Azamatex; +3 Ответить
25. kote 536 19.05.22 11:08 Сейчас в теме
(24) в каком релизе починили?
ИзменениеИКонтроль чувствитилен к пустым строкам, переносам и пробелам, кто визуально в конфигураторе не видно. Сравнивать придется во внешнем инструменте (например, WinMerge), только то, что в секциях вставки должно отличаться.
32. Brawler 454 19.05.22 20:00 Сейчас в теме
(25) Версию уже не подскажу, в актуальных нет ошибок
Некогда реагировало болезненно на проблемы, но сейчас с этим проще.
Пробелы/табуляторы кстати очень видны если включить отображение непечатаемых символов в конфигураторе.
Я всех своих подчиненных прошу работать с включением этих символов, тогда меньше срача из пробелов и табуляторов.
Чтобы непечатаемые символы не мешали работать, им можно задать приглушенные еле заметные цвета.
39. olja-ljaaa 33 28.06.22 15:39 Сейчас в теме
(25) 8.3.19
Я использую KDIFF3 для сравнения. Пример применения описала в статье: https://infostart.ru/1c/articles/1535974/
27. biimmap 1827 19.05.22 11:55 Сейчас в теме
Ради интереса спрошу: Вы всерьёз про 50+ расширений??? Реально думаете что стоит жить в таких условиях? Мне такая ситуация видится невероятным абсурдом! Даже просто разработка на расширениях это уже абсурд!!!

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

Чтоб было понятно насколько эта идея бредовая про кучу расширений:
Недавно коллега рассказал, что у них в организации у каждого разработчика есть СВОЁ расширение. И фишка в том, что объекты в этих расширениях пересекаются. Самое интересное происходит в момент увольнения)))

Что ж делать с таким волшебством? Мне кажется "пристрелить" автора такой идеологии!
LosevI; rybolovlev_ms; ardn; +3 Ответить
28. ardn 622 19.05.22 12:49 Сейчас в теме
(27) так как раз я и говорил о том, что мы постепенно уменьшали их количество. Но это тоже время и ресурсы.
45. LosevI 29.06.23 05:20 Сейчас в теме
(27) Вот прям с языка сняли.
Добавить только хочу вопрос к автору статьи - а вы зачем на компании "архитектором" работаете, чтобы довести базу до такой вот архитектуры от слова ж***? Единственная отмазка принимается, что это сделали до вас.

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

Вас не смущает, что платформа не дает никаких адекватных отчетов по тому, как, чем и в какой последовательностии был расширен объект, когда на него смотришь в коде основной конфигурации? А то что расширения друг друга не видят? Логику общего назначения вы где пишите, в отдельном расширении? Да любой Пупкин может расширить объект в своем расширении, который ему расширять не следовало, сломать его, а потом пойди найди среди 50 расширений кто это сделал! И это вы еще не сталкивались с фантомными багами, когда расширение непрописанного в основной конфигурации обработчика модуля объекта тупо молча не отрабатывает без всяких на то причин? И с ролями доступа вы наверное тоже не работаете, с багами и болью не сталкиваетесь? Да о чем я вообще, у вас хотя бы 1000 методов типовых дописано? А то если доработки реально промышленного масштаба, то я не выкуплю, как вы все еще на этом живете.

В чем смысл "упрощать" обновление релиза поставщика, чтобы затем хапнуть втридорого по времени на проверке всех вместо и изменений и контролей, имея кучу потенциальных шансов ошибиться, так как смотреть все приходится визуальным скроллингом? Когда можно просто все железно проверить в дважды измененных при обновлении конфигурации без расширений?

Расширения – это вообще хорошо, это все знают. Я до сих пор остаюсь фанатом расширений

Компания 1С разработала механизм расширений исключительно для патчинга своих типовых решений, просто потом там у них кто-то слишком умный решил, что отдать это в массы и начать пропагандировать - отличная идея. Подгорает с того, что люди не в курсе. Так и пошли эти все проекты с разработкой "на расширениях".

Как жить? Поменять архитектора, нанять программистов в штат, перевнедриться с нуля по единым стандартам разработки.

P.S. Отдельный котел в аду для тех, кто выпускает продуктовые расширения (да еще и хреновенько работающие). Привет Алексровичу с ютюба.
30. TimurD 6 19.05.22 16:38 Сейчас в теме
А как вы типовой релиз обновляете? Потом руками код мержите в расширениях? Я недавно занимался этим неблагодарным делом. УТ 11.4, все доработки в расширении (только код). Кроме как в ручную сравнивать тексты модулей (по методам), скажем, с помощью KDiff, я не нашел. Тот еще ад. Поэтому расширения - это зло в промышленной разработке. А если контора маленькая и доработок особо нет, то можно меньшими усилиями и в расширении запилить.
monkbest; LosevI; ardn; +3 Ответить
31. ardn 622 19.05.22 16:48 Сейчас в теме
(30)
се доработки в расширении (только код). Кроме как в ручную сравнивать тексты модулей (по методам), скажем, с помощью KDiff, я не нашел. Тот еще ад. Поэтому расширения - это зло в промышленной разработке. А если контора маленькая и доработок особо нет, то можно меньшими усилиями и в расширении запилить.
Как писали раньше, обновляешь - расширения отваливаются, чинишь.
35. TimurD 6 20.05.22 09:33 Сейчас в теме
(31) А если не отвалится? Кто даст гарантии, что все ок?
monkbest; ardn; +2 Ответить
33. Brawler 454 19.05.22 20:04 Сейчас в теме
(30) Не могу согласиться, что расширения ЗЛО.
Если не можете аккуратно вести разработку, то и все прочее будет ЗЛО!
Расширения позволяют изолироваться от типовой конфы и не переживать сильно что заденешь именно типовой код или типовой объект и сломаешь его.
В расширениях платформа предоставляет прекрасный механизм (да не идеал) поиска того что сломалось с последнего обновления.
Конечно никто не отменял сначала прогонять обновления баз на тестовой базе + починка расширений и уже потом на рабочей базе применять.
olja-ljaaa; gmw; ardn; +3 Ответить
34. TimurD 6 20.05.22 09:31 Сейчас в теме
(33) В большей части задач мы затрагиваем типовые механизмы, так или иначе. Согласен, если сбоку напилить какой-нибудь функционал, вряд ли он сломается или сломает что-то при обновлении. НО, когда мы лезем и меняем (дорабатываем типовой кот), случиться может что угодно. Во-первых директива &Вместо: код у поставщика поменялся, а мы забыли его проверить и оставили старый. Может сразу при тесте все упадет, а может и нет. Может когда уже сформируются некорректные данные в базе, тогда мы поймем, что накосячили при обновлении. Во-вторых 1С не умеет сравнивать основную конфу с расширением(ями). Все нужно делать руками, при чем проверять весь перехваченный (как минимум) код. А тезис - если что-то сломается мы тогда посмотрим... Это просто не профессионально. Разработчик ответственен, что обновление встанет корректно (не берем во внимание данные).
Когда появились расширения я откровенно за них топил, спорил и ругался с коллегами. Но поработав с ними пару лет (с расширениями), хапнув Г*, пересмотрел свое мнение, т.к. ошибался.
nano1c; ardn; +2 Ответить
36. Brawler 454 20.05.22 10:08 Сейчас в теме
(34) ИзменениеИКонтроль очень помогает если руки лезут в типовой код и платформа сама сообщит что у вас есть то что нужно исправит.

Контроль на уровне дерева метаданных есть, переименовали реквизит в типовой, вы об этом быстро узнаете.

4 года использовали в расширениях свои обьекты для хранения данных. Свои реквизиты тулили в типовые объекты.

Да бывало в платформе гклюки, но 1С сильно вылизали платформу по этому поводу, сейчас все более менее стабильно пашет.

А новые режимы совместимости несут больше плюшек, жаль типовые выше 8.3.17 пока ведкость
40. olja-ljaaa 33 28.06.22 15:45 Сейчас в теме
(30)Здравствуйте! Раньше тоже с ужасом смотрела на вынос доработок в расширение. Затратно по времени и кропотливо. Но, результат по дальнейшему обновлению конфигурации меня очень порадовал. Время на обновление релизов сократилось значительно! Решила свои действия описать в виде статьи. Может что-то для себя подчерпнёте нового ;) Ссылка https://infostart.ru/1c/articles/1535974/
37. ovasiliev 6 21.05.22 14:42 Сейчас в теме
Статья, как обычно в нашем глубокоэшелонированном мире 1С, несёт и изрядное количество вреда.
Менеджеры средней руки и средних же способностей (которых у нас, увы, большинство), как обычно, ищут абсолютных решений - чтобы применил, и оно работало "само". А таковых нет и быть не может.
Взять ту же директиву "Вместо". Конечно, все соображения относительно неё абсолютно справедливые, но ведь без неё нельзя обойтись совсем. Причём и ПродолжитьВызов() в ряде случаев неприменим. Приходится заимствовать весь код и править его. И при каждом обновлении мониторить все эти заимствования, что там изменилось в типовом коде.
И на это надо обязательно обращать внимание в подобных статьях. Иначе вы вводите в заблуждение подобных "менеджеров".
Award; ardn; +2 Ответить
38. ardn 622 23.05.22 08:50 Сейчас в теме
(37)
Иначе вы вводите в заблуждение подобных "менеджеров".

Да, вы правы, многие пытаются найти абсолютные рецепты, работающие всегда и везде, не понимая, что это невозможно
41. investec 01.07.22 15:06 Сейчас в теме
Почему не использовать ОДНО расширение, подключенное к ХРАНИЛИЩУ?
Зачем создавать проблемы, а потом мужественно и упорно их решать? На дворе 2022 год
42. Salavat 13 04.03.23 07:44 Сейчас в теме
(41)Тоже никогда не понимал тех, кто плодит/размножает расширения - нафига?
Даже Два расширения, вместо Одного - уже в этом ("упрощённом") случае, лишние путаница/разбирательство/...!
43. Salavat 13 04.03.23 07:59 Сейчас в теме
Конкретно к применению расширения (даже одного!) для доработок рабочей конфигурации, лично я против.
Т.к. (минимум!):
1. Сравнить (предметно и просто, а не "абы, кабы, что-то,..") с типовой конфигураций - невозможно в принципе!
(это даже - если избегать "Вместо и ИзмениниеИКонтроль" - с ними, ещё дальше в лес)
2. Производительность снижается - https://its.1c.ru/db/metod8dev/content/5940/hdoc
(больше чем на четверть!)

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

Для разрабов на месте - это лишняя морока, только! (включая и п.1)

Да - для внесения корректировок/исправлений (типовых от 1с!) - расширения - это офигенный/реальный плюс!
Только вот многие забывают о факте - эти расширения, делаются именно для того, чтобы быстрее (не дожидаясь выхода нового релиза) исправить.
Далее это исправление - переносится в конфигурацию поставщика!
44. Salavat 13 04.03.23 08:09 Сейчас в теме
Зато ведь, при этом всём (абсолютно реально!) -
- надо показать, что "я в тренде!".
А излишняя/бестолковая возня, это "всего лишь недостаток, который незаметен на фоне безоговорочных преимуществ!".
(Если чо - я специально в кавычках привёл текст - это не моя т.з.!

Я уже в нескольких конфигурациях (ЕРП, ЗУП - в т.ч.!) доказывал (вполне по факту), что применение расширений - никак не ускоряют обновление типовой конфигурации.

Один франч, прямо мне сказал - нам плевать абсолютно -
- как клиент говорит/пишет, ему надо сделать, мы и делаем.
Что с расширениями - часы/сумма выходит больше (в преобладающем большинстве случаев!) - никто не заикался, даже.
Т.к. среди клиентов - тоже есть - "гикнутые на модных веяниях".
Оставьте свое сообщение