Пора уже переходить на EDT?

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

(0) почему ты спрашиваешь?

(2) Да смотрю много где пишут что ETD то, EDT это. В вакансиях активно писать стали. Может пора осваивать начинать?

(3) пока не начнешь пользоваться - не освоишь нормально
изучать ради изучения - забывается быстро

+4 был проект на едт - попользовался, особо сложного ничего нет, есть нюансы
сейчас прошло 3 месяца - уже подзабыл

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

(3) если развёрнута инфраструктура (т.е. типа "настоящие" программеры полезли в 1С и у них уже есть настроенная инфраструктура разработки, контроля кода, тестирования и т.д.), то вполне себе +/- нормально работать - малость необычно, но нужно привыкнуть

Опять же, если в 1С разрабатывают 2-3 человека и разные части системы, то в EDT большого смысла тупо нет
А если нужно переключаться в работе между 7 и 8 в разную логику (Конфигуратор или EDT), то совсем мрак

В EDT есть плюшки, но не той критичности, что "Ай не могу жить" для небольших контор, но очень даже приемлемо для больших коллективов

(6) сила привычки, скорее всего, есть какие-то финты ушами, но не так как в конфигураторе

(8) Сорвал с языка. +100500.
В анкету можно добавить пункт 6 "Конфигуратор привычнее"

(6) "ТЗ в файл не вывести." это как?

(10) https://github.com/1C-Company/1c-edt-issues/issues/698

(11) Понятно.

(1) Внутри этого файла своя файловая система со структурой папок

(3) Пока Вы думаете, другие уже работают на EDT, причём на тех вакансиях, где могли быть Вы.

(0) не оно конечно масштабируется и т.п. великолепно... но вот был ряд вещей которые ранее можно было только в конфигураторе... и вроде 1С подтвердила что в ЕДТ их не будет...
PS А СонарКуб к ЕДТ кто прикручивал?

Не одного плюса не увидел.

Нет смысла

(13) Я понимаю. Не понимаю, зачем нужно было придумывать отдельную систему версионирования через хранилище, если была возможность использовать наработанную годами на движках как у GIT.

(14) Все понял. Тогда учусь работать в ETD.

(0) Мне кажется не корректно сравнивать горячее с зеленым.
Конфигуратор для небольших групп разработчиков. EDT для больших. Организация работ разная.

(16) (17) не всё так однозначно,
для одного - слишком большая инфраструктура нужна (не смысл влезать)
для 5-10 разработчиков - уже можно подумать (так-то единый сервер и возможность поставить автоматический контроль за требованиями к коду, что уже хорошо)
для >10  очень, возможно, что преимуществ у EDT будет больше, но всё зависит от количества различных конфигураций

(18) Сопутствующая инфраструктура - не всегда имеет смысл разворачивать GIT и т.д. + некая замкнутость системы - работа в рамках одной логики (более плавный переход от 7 к 8)
Кроме того, распространяют CF (или MD для 7) и изначально нужно подготовить EDT и GIT (не у всех хватит квалификации, многие в 1С пришли из других сфер - мощи хватает внести правки, но на большее нет)

(14) в чем плюс EDT перед хранилищем, что за него больше платят?

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

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

1С-ники перешли на EDT и теперь сравнение конфигураций выдает чушь, постоянно какие-то пустые строки/пробелы, какие-то синонимы на формах.
Сломали сравнение/объединение и пофиг. Может стоило бы кого-нибудь оставить в конфигураторе, чтобы они видели что сломали?

Ну если мыть шею под большое декольте, тогда, наверно, нужно.
Если работаете в небольшой компании и правите типовую конфу в пару-тройку рыл - думаю, нафиг не надо. Зависит от.

(22) Плюсы есть для разработки, но для "оперативно поправить прямо у клиента" EDT ни каким боком не подходит
Сравнение объединение в EDT имеет больше плюшек (изменённые дважды - т.е. внёс изменения разработчик и поставщик, EDT разрулит на 80-90%, а конфигуратор только руками)

так

(24) В конфигураторе такое сравнение штатными средствами реализуется. Если мало, можно подключить инструменты сравнения используемые в EDT.

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

(22) про git слышали?

(28) слышали. Это когда на сайте свой код хранить можно, а любой заходит и смотрит, и даже скачивает.

(1) <а не как у всех проект со структурой файлов.>
потому что ты с метаданными работаешь, а не со 100500 файлами, еще вопрос, стоит ли брать пример с С/CPP где h-отдельно cpp - отдельно, ну и ресурсы гдето кучкой свалены или какуюнить яву где xml-ный ужас из спринга гденить лежит

===

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

(29) Вы путаете с github

(30) А в 1С это разве нет так?
Представь если бы С/CPP свои проекты вконце упаковывала бы в zip и ты получишь полный аналог того что делает 1С (1 файл, а внутри куча файликов (таблиц))

(29) git - это технология. А где она развернута, у себя или в публичных облаках, это уже вы решаете.

(32) 1C это делаем всё сама, а в C/CPP все вручную, и потом еще ковырятся в 100500 вложенностях исходников

(34) Что она делает сама? Попробую сравнить изменение в хранилище версии 1567 с версией 1324. На гите это секунда, а через хранилище 1С больше часа в зависимости от железа.

(34) В исходниках ковыряться не нужно. Все за тебя IDE делает. В разрезах удобных для разработчика.

(24) 1. в расширении храните свои поделки.
2. Все изменения один раз сохраняешь потом подгружаешь эту xml и нет проблем.

(35) "сравнить изменение в хранилище версии 1567 с версией 1324" - звучит как клиника

(0) Если возникает подобный вопрос, значит одно из двух:
1. Либо вам совсем нечем заняться и вы маетесь от скуки.
2. Либо вам оно не нужно (если бы было нужно, знали бы - зачем).

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

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

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

(38) иногда и такое нужно, но у меня максимум 15 минут было. Вот режим "Сравнить / объединить с хранилищем" - это, да, 1,5 часа могло думать

(39) тут больше вопрос технологичности:
1. политика "Всё в одном флаконе" - конфигуратор + хранилище = счастье (на 7 и простой конфигуратор изначально был счастьем)
2. политика "разрабатывайте как хотите" - EDT + Git + всякие примочки контроля кода и тестирование = счастье

изначально 1С пошла по пути 1 (что +/- оправданно с учётом выстраивания своего стандарта работы + не сильно большие требования к квалификации персонала),
сейчас поворачивается в сторону 2 (что является просто переходом к другой политике и само по себе ни плохо, ни хорошо, но требования к инфраструктуре и квалификации вырастают, как я понимаю, высвободились большие конторы из "настоящего" программирования, у них уже развёрнута инфраструктура + квалифицированные админы + привычка разработчиков и запихивать их в конфигуратор так-то неправильно)

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

Если команда большая, то конечно нужно. Например есть общий модуль отвечающий за интеграцию с другими системами, либо идет активная доработка некого документа. Допустим популярного типового Реализация товаров и услуг. И разработчики вынуждены ждать пока один поработает, выложит решение в хранилище, потом другой. Либо идет параллельная работа за счет Git. Для больших команд однозначно нужно. Да и для небольших тоже плюс, например если 2-3 разработчика работают над чем-то одним. Например над тем же типовым документом. Просто один свою часть делает, другой другую.

(42) Глупость полная, можно на примере реализации пример.

(43) Пример простой. Один разработчик должен с реализацией одну пользовательскую историю реализовать, другой другую. Причем в первом случае одни новые проводки, в другом другие. Если работаем через хранилище то один разработчик будет вынужден ждать пока другой реализует свою пользовательскую историю и отдаст документ для реализации своей. В случае Гита такой потребности нет. Более того разработчки могут выкладывать свои коммиты в гит и обновлять свои ветки решений для избежания конфликтов, когда решения пойдут в мастер ветку.

(44) Имеется виду забирать другое решение через черри пик.

(44) оба пользуют после проведения куда пишут свою лабуду. так и знал что пример будет дурацкий.

(46) Мысль раскройте. Что вы имеете ввиду непонятно. Пример не дурацкий а обычный рабочий.

(47) 1. каждый работает в своем расширении
2. Каждый работает в своей конфе и изменения вносит только после того как отладил.

(42) все равно не пойму как можно править один и тот же код, там какие-то фишки по сливанию доработок в один модуль? Даже если одну процедуру дописывали?

(49) да, типа по временной метке исправления сливается код + при проблеме идёт уведомление админу и разруливает человек

(47) разработчик 1, создал какой-то свой ОМ, или что-то, позволяет ему вести разработку. Пустую заглушку с вызовом какой-то точки входа (которая сейчас ничего не делает) он влил в хран. Второй сделал так же. Дальше оба захватывают только свое и сидят там до укаки. Если механим какой-то уже существующий, то возможно где-то в ОМ нужно точечную инъекцию развязки сделать, поместить в хран с заглушками и все. В части же расширений - каждый чел в своем расширении. Конечно, если оба механизма как-то пересекаются, или это вообще нечто единое, просто два разных сценарий, такое деление - излишне, но кому охота при рефакторинге может замерджить все в нечто единое. Но как правило никому не охота. Но с вами согласен, такой гибкого мержджа, как в едт, где все эти заглушки, подливы технические не нужны - на обычном хране в клик не получишь. Я смотрел, как там народ выходит из положения путем поставки на поствку и что-то там еще - но это, как мне показалось, еще хуже. Поэтому на хранилище жить можно, обычно все на нем и живут, но в гите, исключительно на едт - конечно жизнь в тыщу раз приятнее. Но, думаю, это + сравнение форм при обновках, плагин на проверку стандартов - это и есть, прям вот такое, от чего хочется в ней работать. Но, и дегтя тож много.

(44) Merge в Master - это кусок каки, я прямо был удивлен, что в git-е нет захвата.

Вообще, конечно, идеально было бы комбинировать - когда хочешь - захват, когда хочешь - параллельно.

(52) как работать с захватом если на проекте например человек 5 разработчиков с разными задачами?

(54) Постучать по плечу и попросить на выход.

(49) кто опоздал с мерджем в мастер (пулл/мердж-реквестом) тот и подтягивает свою ветку к актуальной

(55) тебя самого попросят, у всех сроки горят и задачи разные, в некоторых случаях это даже другие отделы могут быть

у меня (не в 1С) был проект, там около сотни человек над одним проектом работало, в ci/cd даже merge train был чтобы автоматом изменения мерджились и когда туда в очередь встаешь он сам проверяет на наличие конфликтов...я разок за сутки раз пять ребейзил свою ветку потому что ктото успевал зарелизится впереди и мне приходилось мерджить его изменения

я вообще не представляю как в таких условиях блокировать объекты от изменений

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

(52) Это условное выражение. Обычно есть специальная релизная ветка, которая уходит потом в мастер.

(61) это если релизы выделенные, сейчас модно Continuous Deployment, и ветки сразу в мастер мерджатся и выкатываются на прод

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

Зачем устраивать холивар на тему "git vs хранилище"?

EDT имеет смысл только для взрослой постоянной разработки, где действительно могут быть востребованы все те функции которые даёт EDT.

А для рисования печатной формы счета-фактуры в БП 3.0 или какого-нибудь разового отчёта в УТ развёртывание EDT - сомнительная (мягко говоря) идея.

(42) И в чем крутость ? люди могут парралельно разрабатывать и без GIT и ЕDT  с обычным хранилищем. Один хрен потом соединять все вручную что там , что там