Всем привет. Подскажите пожалуйста это нормально, что мы внесли правки в конфигураторе, затем нажимаем F5 и ждем пока база откроется минуты 2, затем тестируем, если находим ошибку, снова повторяем эти же действия? Ну т.е. в других языках программирования все происходит за 10 секунд, а в 1С, особенно если база тяжелая, приходится ждать долго пока отроется база. Может есть другие способы тестирования?
спасибо.

Вам норм сравнивать языки программирования с тяжелой базой?

вносите правки в расширениях )

есть Vanessa Automation

(0) а вы в других средах программирования что-то сложнее "Hello, World" делали? Но в целом да, 1С тяжелая платформа

(0) Во внешнюю обработку код пихни и отлаживай в ней
(2) Все равно перезаходить ))

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

(6) менять структуру полей в расширении для любителей

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

(7) это только для отладки. потом все переносить в конфигурацию. хотя лично я предпочитаю хранить в расширениях и допреквизитах

1. У конфигуратора есть ряд утечек, которые со временем удлиняют обновление конфигурации. Перезапуск конфигуратора их естественно устраняет.
2. Можно сделать замер производительности старта сеанса. Там еще много времени может занимать выполнение прикладного кода, который иногда можно отключить настройками, а иногда можно что то в нем поменять для ускорения.
3. В ряде случаев можно использовать внешнюю обработку и отлаживаться в ней, пока не потребуется вносить правки в объекты конфигурации.
3. В ряде случаев можно использовать консоль кода (например из подсистемы "Инструменты разработчика Tormozit"), в которой можно очень быстро вносить изменения и сразу выполнять код, но без создания методов и без работы с формой. Это - самый быстро перезапускаемый режим, но и самый ограниченный.

(0) Разработка через тестирование - не лучший путь для 1С.
Не надо делать столько много ошибок, чтобы перезапускаться с частотой более высокой, чем время загрузки проекта.
Если же от подхода пошаговой разработко-отладки отойти невозможно (иногда такое бывает), то меняйте способы. Например, пункты 3 (оба пункта или один из них) из поста (10).

(0) купи i9-13900kf

(12)+ будет меньше минуты на ERP УХ
на БП мгновенно

https://xkcd.ru/303/

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

(10) Сергей, может плохо искал, консоль кода позволяет отладку в самой консоли(ну а вдруг)?
использование процедур в коде возможно?
типа
<некий код с вызовом Процедура>

Процедура ...

(15) вы нашли друг друга, можно организовать клуб )

(17) Это только иногда) Я всегда стараюсь избежать такого. Если какой-то код можно отладить через внешнюю обработку, то это спасает.

(15) как раз с формами, тем более новыми, перезагружаться необязательно

Создаешь во внешней обработке форму документа, назначаешь реквизиту формы Объект тип - ДокументОбъект.мойДокумент
и отлаживаешься без перезапусков

когда до идеала довел - копируешь форму из обработки в конфигурацию

(16) Пошаговая отладка в консоли кода (ИР) есть только через динамическую внешнюю обработку в конфигураторе.

(16) Ты писал "использование процедур в коде возможно?"
А я в (10) писал "без создания методов"

Я тут еще пожелание в 1С написал про горячий перезапуск клиентского приложения из конфигуратора. Как думаете реально сделать малыми затратами?
https://github.com/SeiOkami/OneS/issues/197#issuecomment-1516175107

Лучше конфу хранить в открытом виде в СУБД в нескольких таблицах

(23) почти turbomd

(24) Как этим удастся решить проблему долгого запуска?

(26) Естественно следующий шаг это при выполнении брать код модулей напрямую из базы
Не потребуется распаковка и получение в кэш

(27)+ Аналог как было у 1С 7.7 #ЗагрузитьИзФайла <ИмяФайла>

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

Спасибо всем за ответы, буду пробовать. Но в целом, странно, разработчики 1С знали и закладывали методологию того, что базы будут большие, а чтобы их отлаживать, получается нужно выдумывать свои костыли, внешние обработки и пр. Я к тому, что когда на экзамене Специалист запускаешь отладку, там это 5 секунд, т.к. база легкая. А если ERP кто то отлаживает, это конечно не я, но просто интересно )) бывает при доработке часто ошибаешься, и по каждой мелочи приходится перезапускать, и ждать по 5 минут 20 перезаходов, это как то так себе решение.
но всем спасибо))

(30) Самое хреновое это километровые запросы отлаживать где даже выгрузки в ТЗ нет
И через много уровней процедур/функцийпробрасывают выборку из результата как параметр
И на каждом правят

(30) Разделяю Вашу боль. Но если отладка есть, это уже счастье. Попробуйте ошибиться в программе микросервиса, где запрос уходит в очередь Rabbit MQ и там что-то происходит в третьем микросервисе...

(31) Это на какой платформе запретили выгрузку в ТЗ? У меня на 1С8 работает везде.
Выборку из результата запроса править нельзя. Она только для чтения.
Править можно только выгрузку из результата запроса.

(0) "все происходит за 10 секунд" – счастливчик, ты не отлаживал программы на Scala...

Запросы прекрасно бьются на части
Временные таблицы выгружаются в таблицы значений и загружаются обратно.
Тут как раз все просто.

Сложно,кошда алгоритм,который не делится на куски.

Недавно столкнулся в ЗУП с методом УчетНДФЛ.РассчитатьНалогПоОсновнойСтавке, который содержит 2566 строк. И это не текст запроса, это именно код, который содержит тексты запросов, много кода, комментарии пояснений шагов. Но более 2500 строк кода!
Пистаели типовых вообще читали про чисты код и чистую архитектуру?

(32) даже если микросервис поддерживает другая команда, есть общая кодовая база, где можно глянуть, что именно у них ошибка.
накрайняк, завести баг на другую команду.
и обычно все обмазано логами донельзя, трейсингом и прочим (а иначе как?).
к этому все равно приходят рано или поздно, если микросервисом дохуа, то есть делают платформенный фреймворк с observability, то есть заготовка микросервиса, в котором инфраструктурные вещи почти все написаны, если надо что-то - тащишь платформенную либу, где тоже все обмазано трейсингом и логированием.
трейсинг вообще прикольная штука, и в 1С тоже можно было бы, если бы оно работало по UDP.
честно, отлаживать в 1С было сложнее, чем сейчас, когда столько логов и прочего.

и да, когда работал с 1С взбешивало, что даже на свежем компе приходилось ждать перезапуска клиента.
сейчас пишу микросервисы на Go, задачи сложнее инженерно, приходится больше продумывать про архитектуру и т д.,
но при этом всем, запуск экземпляра приложения занимает не больше 5 секунд.
естественно, если бы я писал что-нибудь монолитное а ля 1С и не на Go, запуск наверное тоже был бы долгий == компиляция + миграции (если нужны).

(37) Читали. Но никто не обещал им следовать :-) ... Когда восьмерка только-только радовала первыми релизами довелось читать их рекомендации по кодированию. Там было пожелание, чтобы кодировать так, чтобы не появлялось процедур  и функции длиннее нескольких сотен строчек (кажется трех сотен, могу соврать). Было очень любопытно после этих рекомендаций от самой 1С разбирать коды их типовых :-) .