Условно 10 человек в команде, совместное хранилище, каждый захватывает свой объект для реализации активностей.
Допустим программист Петя захватил Модуль1, внес в него свои изменения и как это бывает на практике затянулось принятие по причинам не зависящим от Пети.
В этот период у программиста Вася срочная задачка и очень нужно внести изменения в Модуль1. Вася пишет Пете. Петр сознателен и помогает коллеге и отпускает Модуль1.
У Васи все хорошо, он сдает задачу и через определенное время возвращает Модуль1 Пете.
Минусы у Пети. Нужно где-то сохранить свои доработки по задаче в отдельной базе или файле конфигурации. При необходимости вернуться сталкиваемся с проблемой как понять, что именно эта дельта была изменена.
База непрерывно меняется, может релиз новый прилететь, а Пете нужно оперативно вернуть все изменения и продолжить работу по активности.

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

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

а если пытаться все вести в одном хранилище, то да, получим трандец

https://infostart.ru/1c/articles/864097/

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

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

(0) Каждый работает в своей и далее вносит доработки в рабочею - на 10 человек работает.

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

(0) мы ведём разработку в отдельных урезанных клонах продуктива, в хранилище код передаётся после приёмки функциональным заказчиком
вариант захвата более чем на 5 минут исключён

(0)
1. В основном задачи должны распределятся по объектам справочники документы регистры итп.
2. Если же что то нужно в общем модуле разрабатывать то можно же временно кому-то использовать другой похожий модуль или код пока писать в документе?
3. На крайний случай кодить в пустой конфе без хранилища потом перенести ее к себе или в хранилище.

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

так EDT и GIT же

(6) Хороший ход. Только может получится, что ты хочешь внести изменения, а уже много произошло и ты адаптируешь под эти изменения и пока переписывал еще что-нибудь добавили.

(10) не может получиться, технические релизы выпускаются по плану

Если вы почитаете разные статьи на ИС про совместную разработку, например

https://infostart.ru/1c/articles/903269/
https://infostart.ru/1c/articles/1127356/
https://infostart.ru/1c/articles/1443756/
https://infostart.ru/1c/articles/1452242/

и ещё пару десятков других, не пропуская комментарии, то вы поймёте, что совместная разработка в 1С - это вам не пописать сходить.
Народ вовсю занимается велосипедостроением с граблями, причём, EDT+GIT нифига не спасение, а скорее наоборот.
Читайте, думаёте, пробуйте, собирайте свой комбайн.

(11) А если разраб не успевает к плановому релизу закончить свою доработку?
Мне видится, что ничего криминального в этом нет.

(0) почитайте про Git

(0) код - комментируется номером задачи
изменения в формах - по максимуму кодом + коммент в модуле формы с номером задачи
когда сливаешь - достаточно прозрачно
да, мусора много

(15) точно не вариант
потом начинаются лесенки закоменченых и прочих

> А как это сделать в 1С, без ... отдельного хранилища для каждого разработчика
Почему нет? Ведь в гите подобным образом и делается. У прога отдельная ветка на фичу

(15) Чтобы было прозрачно при сливании, нужно трехстороннее сравнение
- Базовая конфа
- Прог 1
- Прог 2

Наподобие как выполняется обновление измененной конфы на поддержке:
- старая конфа поставщика
- новая конфа поставщика
- кастомизация

(18) поставь уже EDT
но какую версию стабильную взять сча не в курсе

(19) так я не для себя, я для людей советы раздаю

(19) edt - убожество позорное.

(13) [А если разраб не успевает к плановому релизу закончить свою доработку? Мне видится, что ничего криминального в этом нет.]
В такой ситуации разработчик получает клон продуктива после тех.релиза, переносит в него свои наработки и продолжает работу.
За время разработки может смениться и релиз 1С, важно, что функциональный заказчик принимает работу на текущем релизе

(0) >> Совместная разработка. Как такое в 1С решается?

1С уже всё придумало за вас.
Технология разветвленной разработки конфигураций.
https://its.1c.ru/db/v8std#content:709:hdoc
В вашем примере Вася разрабатывает исправительную версию, а Петя - плановую.
В любом случае каждый должен вести разработку в отдельной конфигурации.

При работе в команде 10 и более человек и достаточно высокой интенсивности параллельной разработки (одновременно с одними и теми же объектами метаданных) следует подумать либо о переходе на Git, либо об использовании СППР.

(23) гит там вообще никаким местом не поможет

(21) Идея там прекрасная
Но вот реализация через одно место и постоянные баги

(24) >> гит там вообще никаким местом не поможет

🤔
Я в том смысле, что в Git и в хранилище 1С разный подход к параллельной разработке одного и того же объекта метаданных.
Параллельная разработка одного и того же объекта в одном хранилище 1С невозможна. Чьи-то изменения должны быть помещены в хранилище, чтобы кто-то другой мог работать с объектом.

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

(24) как раз GIT поможет

(27) >> работают независимо далее сохраняют свои конфы

Конфигурации в любом случае будут отдельными.
Это не имеет прямого отношения к вопросу о том какая система версионирования используется - git или хранилище 1С.

>> это игрушка для быдлокедров

git или хранилище - это всего лишь вопрос выбора конкретного инструмента.
Инструмент никак не зависит от того кто им пользуется  - быдлокодер или просветлёный мегагуру.

>> из мира где не работают с метаданными.

Про это вообще не понял.
Такое подозрение, что ты говоришь о работе с git'ом какими-то инструментами, не умеющими работать с метаданными.

(29) Под быдло-кодером я подразумеваю человека который просто набивает код = работает с текстом.  
Да
, в гит ты не сможешь из коробки сравнить две конфы и за пару кликом разрулить все проблемы, пойдешь искать какой нибудь виевер, формы в гит как будешь выгружать? макеты как будешь сравнивать? А главное нафига это всё нужно, когда уже всё есть?

(30) Сразу видно что вы EDT в глаза не видели

(31)+ как это ни странно то оно даже формы нормально сравнивает а не только когда кодом
но бывают изредка разные приколы
когда при автомердже фигась и нечто пропало куда то

(16) ну почему же? про мусор - это да, но зато точно известно, что, кто и когда сделал
вопросов у сливальщика не возникало никогда

(33) вопросы сливальщика должны решаться трехсторонним сравнением
а то получается нужно постоянно терпеть мусор в коде только для какого то разового действия

(34) но в тоже самое время надо удобно видеть всю историю изменений
а не как в хранилище у 1с с дикими тормозами

(35)+ да я согласен что комменты в коде аля история это глупость и изврат, когда много раз переделывают-допиливают
потом это превращается в нечто дикое

(30) >> в гит ты не сможешь из коробки сравнить две конфы и за пару кликом разрулить все проблемы, пойдешь искать какой нибудь виевер, формы в гит как будешь выгружать? макеты как будешь сравнивать?

Значит я угадал в своём предположении, что ты говоришь о работе с гитом исключительно его инструментами. )))
Конечно же ты прав, что с 1С с гитом из коробки как он есть работать не получится. Нужен либо EDT, либо инструменты для сборки конфигурации из гита и последующего сравнения/объединения конфигуратором 1С.

>> А главное нафига это всё нужно, когда уже всё есть?

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

(31) видел - до версионнирования там не дошло ибо слишком блевотно. Прошу заметить что я также на пхп и джава работаю. НО вот конкретно неудобство едт выбесило.


(37) Приведи пример когда едт может, а конф нет.

(0) Использовать Git. При этом EDT не обязательно.

(30) Да уже куча есть приблуд для Git. Кто работает с Git через командную строку это какие-то особые человеки

(40) дурачки качают гит, затем приблуды и получают что то типа конфигуратора - ура!

(38) >> Приведи пример когда едт может, а конф нет.

Ничего такого нет и быть не может. По определению.
Это вопрос выбора конкретного инструмента в конкретной команде.
Для кого-то EDT блевотно, для кого-то - конфигуратор - недоIDE-инвалид.

(42) можно примеры инвалидности?

(43) да какие там примеры недоЕДТ и блевотности. Так, очередная попытка усидеть на двух стульях

(43)
Конфигуратор:
Тупой рефакторинг - переименование, который тупо по имени процедуры/функции работает
Не обращая внимания на имя общего модуля через точку перед именем процедуры/функции

(45)+ Пипец медленный поиск/отбор в Конфигуратор по дереву метаданных и по конфе

https://its.1c.ru/db/edtdoc

(46) "Пипец медленный поиск/отбор в Конфигуратор по дереву метаданных и по конфе" - мой ай7 10 лет давности ищет быстро ты видимо пользуешь говно стойки от говно админов.

"Тупой рефакторинг" - нормальный программист фигеет с таких заявлений.

(47) не надо нам ваших голубых книг.
Приведи пример кода где рефакторинг работал в еди лучше - люди хоть оценят упоротость кода

хочу плагин к EDT, который умеет с хранилищем конфигурации напрямую работать...

(50) 1. Чем EDT удобнее в смысле версиоионирования - конкретный пример
2. Чеи EDT весомо удобнее типового конфигуратора?

Просто вся эта EDT походит на секту лгбт - "мы не такие! мы имеем права! любите нас за это!"

(51) Это бесполезно объяснять
Для начала EDT может использовать все ядра компа в отличие от Конфигуратора

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

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

(25) Ну вот кстати нет. Два года назад ЕДТ уже был вполне живенький, на котором спокойно пилилась ЕРП.
Редкие баги не сказать чтоб сильно мешали.
Но сейчас в ЕДТ уже столько всего пофиксили и доработали, что особо не докопаешься.

(55) Скажи какую версию EDT я могу использовать для платформы 1С 8.3.22.1709 ?
Что это если не чуко не БАГИЩЕ

(56)+ 2022.1.5 умеет только до 8.3.21
2022.2.4 умеет только с 8.3.22.1750

И???
Как мне с платформой 8.3.22.1709 работать?
Перейти на другую пока никак.

(54) давай с при еров то прото трем как и любой солага из быдлокодингс

(58) давай с примеров то просто треп как и любой салага из быдлопрогеров

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

(0) это проблема архитектора, разработка ведется так

1. общее хранилище, рабочая база НЕ подключена к нему
2. новые объекты с захватом корня добавляются только когда нет больших незакрытых доработок
3. новые объекты помещаются в хранилище сразу с "заглушками", потом корень отпускается и пилятся эти объекты
4. ну и конечно архитектор не должен давать конкурирующие задачи
5. если все-же конкуренция есть, то один разраб ставит "заглушки" и отдает в таком виде
6. на продакт релизит один человек за всех

(1) гамноподход

(61) ой ли проблема архитектора, ща есть модное слово devops

(60) "Потом,нужно научить разработчиков разбивать код на маленькие процедуры и функции,чтобы не править всем скопом одну мега процедуру."
научить бы искать готовое, чтобы не плодить дубликаты
но как искать - вот в чем вопрос?

(64) а потом пипл жалуется что в типовых глубина вложенности процедур ахеренная - пока дощел что искал - забыл откуда шел...

(61) зачем сразу помещать новые объекты в общее хранилище? с какой целью?

(36) зато по комментариям например легко отследился случай когда через 17 итераций переписывания одного большого отчета за 4 года вернулись полностью к исходной постановке задачи. в гите кто бы стал что было 17 версий назад сравнивать?)

(67) чем хранилище не подходит для этого?

(67) > в гите кто бы стал что было 17 версий назад сравнивать?)
В гите можно автоматические многие штуки делать. например:
"Команда git bisect — это чрезвычайно полезная утилита для поиска коммита в котором впервые проявился баг или проблема с помощью автоматического бинарного поиска."
https://git-scm.com/book/ru/v2/Приложение-C%3A-Команды-Git-Отладка

кек, программисты из тру ЯП даже не задумываются какие в 1С проблемы приходится решать.
ну да, EDT и git.
и каждый коллега в процессе разработки делает веточку от мастера через git checkout -b, когда все готово, git merge, фиксим конфликты и вливаем новым коммитом.

(69) для тех кто пытается работать с 1с через гит в аду есть отдельный котел.

хранилище от 1с да имеет некоторые недостатки, но по сравнению с гитом это просто идеала.

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

в компании со штатными разрабами более эффективен подход когда разрабы сами все обьединяют и всегда работают в последней версии (банально ошибок меньше)

(71) Некоторые недостатки? Сравнение между версиями по 40-60 минут. Даже школьнику было понятно, что при хранении конфигурации в одном файле мы теряем возможность помечать какие были изменения, чтобы не сравнивать каждый раз всю структуру.

>>>Сравнение между версиями по 40-60 минут

это где ???? у меня максимум 2...3 минуты

а потом сравни это со временем выгрузки в файлы и потом сборки из файлов cf там небось более часа выйдет :)

(71) я не предлагал работать с 1с через гит

(73) ну так.. конфигурации разные бывают

(70) 1с просто сделало однажды сделало доступно и всерьеъз

(73) Ну тогда дай рекомендации. Доработанная УТ. Хранилище на диске NVME, с 11:15 запустил сравнение между версией 2567 и 2572, еще не закончено. Между версиями менялось три общих модуля, в двух документах добавлены реквизиты и у одного регистра сведений модуль менеджера.
Вопрос зачем мне сравнивать все, если достаточно получить изменения по вышеописанным оставим в стороне.
Основной вопрос, почему так долго и как ускорить?

(77) > как ускорить
регулярно выгружать в гит, исключительно с целью таких просмотров

Хранилище блин с EDT сравнивают...
Ппц.
Хранилище - это если один разраб хочет версионировать свое детище.
В остальных случаях один гемор.
Нюхнювший git+EDT в хранилище вообще больше никогда не смотрит.
Посмотрите с последнего инфостарта умного человека, который на эту тему доклад делал - все по делу.
Все остальные потуги бежать быстро на костылях только вызывают улыбку.

Ну конечно, если у вас только обычные формы, тогда... мне вас жаль.

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

(77)
32 или 64х версия?
база через SQL перезаливалась?

(71) Ню-ню. А вот допустим есть задача - кто добавил вот этот код, какая это была задача? Через хранилище наверное такой поиск займет вечность. Через историю гит все гораздо быстрее. Если отлажена связь коммит-задача, то разбор необходимости кода резко ускоряется.

(65) ну ладно те, стек вызовов же... но глубина - просто потрясает!

(83) Если в комментариях поставили номер задачи и дату - то ничего искать и не нужно.

(83) не вечность а логарифм - ищешь делением пополам

(85) это ж ужс в коде будет, если везде ставить так

Судя по ветке гитом пользуются те кому необходимо сравнивать годовалый код. Или прям здесь и сейчас понять чем отличается версия 1000 от 2000.
Кто все эти люди и что они делают в 1с - загадка.
За 15 лет в разработке ни разу не возникала подобных задач.

(85) "Если в комментариях поставили номер задачи и дату - то"
И система контроля кода скажет - уберите эту каку из коментов )
Ибо ужас на каждое исправление оставлять комментарий.
А в EDT не нужно никаких коментов. Просто клацаешь на полосу прокрутки и видишь, кто, когда, по какой задаче внес изменения в эту строку (десяток строк, сотню строк).

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

(77) Хранилище по сети подключено или как? Если по сети то там через самбу все делается и очень медленно. Ускорится можно или локально хранилище положить или настроить доступ к хранилищу через tcp или http.

Если у вас не обычные формы, то вообще непонятно зачем использовать хранилище?
Вообще зачем это обсуждать?

+(91) https://its.1c.ru/db/v8322doc#bookmark:dev:TI000001119

В (61) (71) опытный чел все четко объяснил и по делу.

Хранилище удобней ,лучше и функциональней чем GIT в большинстве задач

Сам работал неоднократно с базой на 10 разрабов по схеме указанной в (61) . Никаких проблем не возникало

(82) База без данных, просто конфа подключенная к хранилищу, файловая, на том же диске NVME. 64 битная конечно версия.

(71) "То есть они тупо накидывают а ты разгребаешь."
А почему здесь такая классификация, что если гит, то тупые удаленщики тупо накидывают, а те кто работает через хранилище - они умненькие и не допускают такого?
Почему не может быть наоборот, что с гитом работают умненькие разрабы, а в хранилище тупо накидывают и потом за ними приходится разгребать?

(96) Ты все таки скажи локально подключаешься или по сети?

(98) Ну там СХД. И непонятно как оно физически реализовано. По скорости записи 500-600 мегабайт в секунду. Сейчас еще чисто локально пробую, на своем компе лично. Тоже NVME. Пока 20 минут что-то сравнивает уже.

(99) Закончилось. Итого, где-то 35 минут. На локальном компе, версия 1С 64, релиз платформы самый последний. Сравнивать домашнюю машину и корпоративную, не очень. Но сам факт. В идеальных условиях больше 30 минут.
У кого-то реально за 10 минут разницу между версиями делает?

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

(79) я как попробовал git в работе, сразу протащился как это удобно.
из-за того, что там инкрементальные изменения, очень многие операции сравнения/объединения вообще автоматом делаются при git merge.
это очень удобно по сравнению с хоронилищем, а ля SVN.
(97) людям просто удобнее работать с проверенным механизмом, как хоронилище.
мне кажется, чтобы никто не "накидывал", нужно код-ревью, и неважно чем вы вливаете задачи в "основную ветку".
еще очень важный момент - тесты, которые в 1С мало кто пишет.
но блеать, где 1С и где тесты, сами понимаете.
код ревью в 1С в паре контор видел за 10+ лет,
понимаю, что это тяжело сделать без инструмента, который показывает разницу и позволяет писать комменты к диффу,
в мире тру-программирования - это bitbucket или gitlab, который работает с git'ом.
но сколько там процентов EDT в реальной работе использует? наверное что-то стремящееся к нулю.
поэтому раз железной руки, которая заставила бы переезжать олдфагов нет,
то и инструменты такие несильно развиты.

(102) в одной конторе, код-ревью делалось через инхаус gitlab. в одной конторе писали все в EDT, в другой - в конфигураторе, потом это дело через CI/CD скрипты загружалось в gitlab.

(102) всё верно 1С это RAD накуй твой гид и тестирование - просто не про это - бесполезные игрушки для хипстеров и криворуких.
В 1С есть встроенный механизм для тестирования - куда ещё проще пойти накликать получить xml?

(104) и не поймёшь, шутишь ты или серьёзно

(104) кек, пациенту очень хорошо.
что сказать - слова сеньор девелопера, не меньше.

(106) Еще раз ты как любой, кхм кхм, ты не особо понимаешь про тесты. Твой максимум почитать на инфостарте как потратить неделю на тестирование кнопки. И потом обязательно написать как тестировать две кнопки, та же история с гитом - большинству он не упал от слово совсем. Искать кто накосячил два года назад, как и сравнивать версию 1000 с 7000 - лютая дичь. Впрочем такие как ты прутся, ты ещё наверное на линуксе 10 команд выучил и в соседней ветке кукарекуешь про свободное ПО?

(107) А вы что разрабатываете? Наверное такое ПО где тестировщики это сами юзеры плюс бухгалтерша Марь Ивановна? Не сталкивался с задачами крупного бизнеса, нечего и истерику закатывать.

(108) ну давай приведи уже пример где без тестировщика ты не смог.

(107) забавно такое читать, когда сообщество и сама фирма 1с как раз подтягивается за нормальными процессами с тестированием и гитом, внедряют всякие ванессы и едт

(110) Забавно наблюдать за людьми которые смотрят на 1с и повторяют за ними используя GIT, EDT. Но не понимают зачем это делает 1с и для чего, просто бездумно копируя вещи которые в обычном отеделе автоматизации средней компании не только бесполезны , а еще и вредны , так как отнимают время у разработчиков а выхлопа от них никакого.

(111) за культом карго всегда забавно наблюдать, только причем тут технологии

(111) дак он потом как 1С будет на свой код по два патча в неделю  делать.

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

Пример приведи - зачем эти разговоры не о чем?

(114) пример простой - с типовыми конфигурациями поставляются тесты

(115) Приведи пример из свой жизни чтоб это помогло, а не отнело тупо время. Там много чего поставляется, книжки, у меня ощущение что ты не читал.

(116) Приведи пример из своей жизни где тебе помогло знание того что в байте 8 бит

(116) > Искать кто накосячил два года назад, как и сравнивать версию 1000 с 7000 - лютая дичь.
у тебя много эмоций и мало сути во фразах
причем тут 2 года, и ты реально считаешь что я вспомню какие именно вопросы я решал сравнением версий?

(104) > В 1С есть встроенный механизм для тестирования - куда ещё проще пойти накликать получить xml?
я уверен что ты этим не пользовался
зато я не раз пользовался так называемым unit тестированием из ваннессы, правда неудобно это, ибо платформа не заточена, но в критичных задачах я делал такие тесты

+ (118) такие сравнения я дедал и делаю, ситуации разные бывают

(117) Я говорю о систематической трате времени впустую. Причем гарантии за свой результат ты не дашь. 8 бит помогли в 10 классе когда гоняли данные из двоичной в шестеричную, применительно к жизни почитай про страницы в субд, может поймешь как данные хранить "результативней".

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

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

(107) оу, милорд забыл принять лекарства.
все понятно.

(122) Ты опять без истории где тестирования спасло тебя от порки?

(123) почему я должен что-то доказывать какому-то неадекватному ноунейму?

(124) Ясно, понятно - очередной трёп, сам поди его не пользуешь просто где то слышал вот и скачешь.

(125) кек, еще и манипулирующий ноунейм. все с тобой ясно.

(123) Твой тезис можно сделать проще. Мне пох на новые методики и стандарты, от этого у меня только быстрее задачи будут закрываться, а для меня это не нужно, так как на 10 закрытых добавят еще 20.

(127) Нету тут ничего нового просто школота ютюба насмотрелась. "10 закрытых добавят еще 20" - в целях замедлить процесса конечно можно... но я при схожих обстоятельствах просто залипал на долгие задачи.

имхо говорить что Git не нужен могут только не опытные
те кто с ним не знаком и не умеют работать

а EDT это просто инструмент умеющий работать с Git, ибо с ним не умеет нормально работать Конфигуратор 1С

чисто технически даже для одиночки Git в связке с GitHub очень удобная штука, как привыкнешь
это же прекрасно что твои проектики хранятся с историей в облаке

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

(121) "Юнит тестирование ..... да вот оно полная бестолковость"
Ахахах. Во всем мире IT проект без автотестов и проектом то не считается, так поделка.
И только одинэсники будут отрицать очевидное.
Ты еще расскажи разработчикам типовых, что юнит-тестирование - это полная бестолковость.
Давай, разработай какой-нибудь продукт, которым будет пользоваться много клиентов.
Любой.
Десктоп, веб приложуху, мобилку или конфу на 1С.

https://v8.1c.ru/news/kak-my-testiruem-1s-erp.htm
Объясни ребятам, что они глупцы.
И что если они при разработке не видят косяков, то и разрабы они так себе.

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

(130) +100

(131) Тесты в масс-продукте внутри фирмы 1с оправданы потому что они делают типовой массоовый продукт.
Для обычных разрабов эти тесты бесполезны в 99,9 % случаев.

(133) Это только у 1С такая особенность? Я в институте помню юнит-тесты делали, даже когда калькулятор писали. Или стандарты другие уже.

(134) +1, из недавнего
расчеты в штуке, которая рейтинги считает, забил ожидаемые циферки, написал make test, и збс.
если что-то кто-то в коде поменяет, тесты упадут и проект вообще на staging не соберется.
проверка множественных сортировок в списках туда же.
в общем, прикольная штука, 1Сники такие вещи обычно в обработках пишут.
и да, хорошо, когда бизнес при оценке сроков учитывает время на написание этих самых юнит-тестов.
с другой стороны - плохой юнит-тест скорее вредит, чем приносит пользу.

(134) потому что калькулятор - это мощь.
Не то что вот это например пустяковое списание партий через решение СЛАУ.
Внес там одинэсник на каком-нибудь 100500м уровне вложенности общего модуля изменения для своей кнопки, которая печатает комментарий, да случайно какую-то переменную задействовал, которая на 200 экранов вверх уже используется и себестоимость по одному месту. Комментарий в своей ПФ то он безусловно проверил, зачем тесты?
Он ведь настоящий одинэсник и обязательно протестировал в том числе  и себестоимость, и производство и сведение годового баланса. Потому что это сц очень уверенный в себе одинэсник!
Такому тесты не нужны.

(130) >Я в вебе с ним работал - там он хорош, в 1С так могут говорить только те кто тупо набивают код. Но не могут сказать что в нем ценного. Была бы польза валялись бы твои проектики на инфостарте а так обычная помойка ничем не отличная от библиотеки фильмов которые пересматривать даже сам не будешь.

Снова не пробовал но осуждаю?
С 1С это неудобно с Конфигуратором, с EDT совсем другое

Как и с другими системами где проект/код/формы не цельным проприетарным куском-файлом а отдельными текстовыми файликами
В этом случае Git идеально

(136) В Golang идеально
Все параметры передаются по значению - по сути это копии исходных переменных

А не как в 1С, где даже "знач" нихрена не поможет
ТЗ если передать по значению - это не копия а всего лишь новая ссылка-указатель на исходный объект
В Golang же переменные и указатели это разные вещи как и во многих больших ЯП
Не получится "случайно какую-то переменную задействовал"

(138) дело не в переменных.
А в принципе.
Есть у тебя конфа, продукт, или еще что-то.
Неважно.
Ты вносишь "незначительные изменения"
И естественно, в полной уверенности, что "вот это я изменил, это же проверил, все ок".
А то что "это" может зацепить за что-то другое - ну так я же опытный одинэсник, не будет такого!
И одно дело, когда ты один, для бабы Глаши в бухгалтерии ваяешь внешние отчеты.
Другое дело, когда вас несколько, а за плечами сотни пользователей (клиентов) с работой в режиме 24/7.
У одного - отработали пару тысяч автотестов по основному функционалу перед релизом проходят идеально и на 100%, он релизит и идет спать.
А у другого, кому автотесты - баловство, накатывает изменения с мыслью - "ну если чо, позвонят".
Разница подходов. Всего лишь.

(139) Судя по сообщениям в ветке, 90% реально для бабы Глаши что-то делают.

(140) ну так автотесты наваять - это обьем работы над задачей x3 если задачи для бабы Глаши. Еще инструментарием автотестирования надо владеть. А где его совить если все время то у бабы Глаши, то у дяди Васи...
.
я тут недавно одному ИП-шнику, который с МП работает - склад обрисовывал на помещение на 900 квадратов почти. "Ну так всё, с 1марта уже на новом складе (этом) будем! Поставим новые стеллажи с прицелом на возможный дальнейший рост и переезд на более крупный склад" - ага, про себя я тихо поржал, есдинственное озвучил - "ну посмотрим, посмотрим... скорее всего вы возьмете БУшные стеллажи и с 1марта не стартанете"... ну так оно и есть - вот две недели марта уже, стеллажи ставят еще БУшные, из положительного - сделали офис на складе двухэтажный как им нарисовал ;-). Так что на все надо иметь сноровку и тренировку, а где их взять если бабе Глаше и дяде Васе - это не нужно или нужно, но даром и быстро..?

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

(141) Автотесты они прежде всего на работу системы по основным задействующим блокам. Чтобы когда хотелка тети Глаши взлетела, не остановился весь бизнес.
А по тестированию, я понял, что пока сам несколько раз в шкуре пользователя не побываешь и не запустишь с наиболее используемыми вариантами, будет на выходе ерунда.

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

ни один "лавочник" платить столько не будет. какие-нить сберьбанки/сибуры/роснефти еще можеть быть, но не бОльшая часть обычных клиентов...

(144) "молучилось хорошо" - читать как "получилось хорошо", а не "мучался хорошо" ;-)

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

(140) тут только дядя Шу и Новиков в крупных конторах.

Волшебник и Асмоди раньше вроде тоже работали в крупняке, но как давно это было-хз


У всех остальных это влажные фантазии

(148) Несколько тысяч сотрудников с мылами это достаточно крупная?

(149) техподдержка такой же конторы у нас в прошлом месяце заняла 10 часов по 1ске, ни гита, ни хранилища у них ессно

Нет

(148) раньше я работал в ГлавСтрое, что бы было понятно количество сотрудников измеряется 6 знаками, и там была 7.7 :)

(152) точно 6?

И чо ты там использовал? Гит? Хранилище? Костыли?

(153) да, в составе ГлавСтроя ГлавМосСтрой, у него на тот момент было 37 производственных заводов и еще до чертиков СМУ... (и это только одна веточка ГлвавСтроя)

(155) все 37 заводов в одной базе?

(154) там не было единой системы, каждый завод сидел на своем, все это стягивалось в единый учет через МОД

(157) ну и о какой организации разработки ты можешь судить? :-) тем более в контексте 8?

Декомпозировать на отдельные системы?

(159) у меня сейчас в отделе пять 1с-ников, этого достаточно, что бы говорить про групповую разработку?

(160) +
ну и с гитом у меня есть практический опыт (по Битриксу)

(160) с моей точки зрения нет, одно дело когда падает 500-600 часов разработки в месяц (7 разрабов в проекте в моменте), а другое дело 1600

Хотя может ддя Бедуина будет релевантный опыт

Ща внедрение закончится и будет падать классические 200-300 часов

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

А в чем проблема использовать Гит? Хотя бы даже для расширения кругозора.

(166) ответ банальный
не смогли освоить

(166) посмотрели поплевались в рамках 1с также как и в едт.

(139) "У одного - отработали пару тысяч автотестов по основному функционалу перед релизом проходят идеально и на 100%" - ты не дашь гарантии потому что это реально баловство.

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

Для выпуска вменяемого (не в стол) продукта требуются нехилые затраты на тестирование

Будет ли оно вручную кучей тестеров-аналитиков или сочетанием/заменой их автоматизированным тестированием пофиг

Покритикуйте идею Конфигуратор -  эмулятор (прокси) хранилища разработки - Git
плиз проголосуйте

(169) ты делаешь сложную систему? Как и 99% сидишь и пилишь одно и тоже и эти тесты нафиг не упали.
А сложным системам тесты не помогают судя по количеству исправлений. Платформа туда же.

(167) Люди которые используют git не смогли освоить хранилище

(123) > Ты опять без истории где тестирования спасло тебя от порки?
Такой типаж сотрудника, у которого основным мотиватором является страх

(72) в хранилище кстати есть такая тема как выборочное сравнение, оно выполняется очень быстро

(174) Учитывая наличие расширений, мне сложно представить в каких ситуацих эти кхм кхм "программисты" свой гкод:
1. Сравнивают версию 2000 с 1000.
2. Ищут чудака которые внес измения пару лет назад.

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

Вы нашли проблему,но за время ее существования вы выпустили несколько версий.
Поиск и анализ позволяют понять,какие версии затронуты.

(176) тиражные решения делают менее 1% но вони в инете более 90%. Про профильные конфы никто не говорит у них исправлений вагон каждую неделю.
Нагло конечно себя, со своим гкодом, под такие решения ровнять.

(172) это про меня. с хранилищем не работал, теперь вот с гит приходится.

(178) Любители делать естественные вещи не через те места такие ...

(175) расширяй границы представлений и мир заиграет новыми красками

(175) к примеру ты когда-нибудь слышал о QA-метриках?

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

Еще не один клоун не привел вменяемого примера. Все только жужат

(182) ты мыслишь костыльно - быстро пофиксить не разбираясь в причинах.аббревиатура QA тебе вообще неведома. Всё верно? Ну и какой пример ты хочешь, ларёчник?

Ещё не понятно, откуда в  твоих примерах постоянно ты два года упоминаешь, балаболка)

(183) Какой то школьник типа тпбя два года ошибся, я смысла не вижу исксть это. Есть проблема я ее решаю а кто ее создал - школьник или вендер вообще боком.


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

(136) ну вот 1С проводит наверное юнит тестирование и что?
Все равно когда они в середине 22 года перехреначили 6 и 25 ФСБУ - у половины моих клиентов посыпались данные.
Потому что например у некоторых клиентов были помеченные на удаление документы "Перевод на малоценное оборудование" на основании которых 1с при обновлении чудесно сформировало проводки которых раньше не было.
И..?
Во всем нужна разумная достаточность.
99.99% клиентам использующим дописанные конфигурации вполне достаточно что бы тестирование производили бухгалтера и простоев, даже с учетом возможных простоев - это все равно дешевле, чем содержать штаты тестировщиков, которые все равно не дают 100% гарантии

(185) такое чувство что вы спорите с оппонентами о разных вещах.
Вы о проектном внедрении и текущем сопровождении бизнеса, а оппоненты о разработке тиражных решений и готовых продуктов.

(187) Я выше писал что тиражные редкость. Судя по мисте все их тестирование примерно следующего вида, пишешь процедуру вешаешь на кномку. Пишешь тест для кнопки. Тестируешь.

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

(187) А кто из них тиражом занимался? У большинства ведь влажные фантазии

(189) о большом и кровавом энтерпрайзе?

Тут столько специалитета, уже бы выпустили серию решений Базуха фо миста эдитед и ЁРП фо миста едитед, с гитхабом, 1С++ и прочими отчетами

(191) на фузине, с микросервисами на го!

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

(193) Главное чтобы время на исправление не оказалось меньше времени на копание, нахождения ответственных и постановщиков, разбор соответствия ФЗ, ТЗ, ТП и актом приемосдаточных ;-)

(193) Опять на самом интересном прерывается. Нашел ты в годовой версии и чего дальше? Кофе пошел пить вместо чая?

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

(194) почему именно это главное? идеальный код, этот тот код который не написан. в нем точно нет ошибок, его не надо поддерживать итд. время на исправление 0 сек.

(194) исправление бага зачастую это поправить одну строчку, а ищешь эту строчку пару дней

(187) для работы в хранилище не нужны тиражные решения и продукты
можно (и нужно) при работе даже в одно лицо иметь историю в хранилище

(196) ты понимаешь сколько изменений вносит 5 программистов за год в конфигурацию?

сравнение на таком отрезке всей конфигурации просто не имеет смысла...

а сравнение одного модуля скорее всего ничего не даст, так как стек вызова около 5 вложений

(196) >>>Вот нужно понять как за последний месяц менялся определенный модуль. Это обычный рабочий момент, который может возникать по 20 раз за день.

Зачем это нужно? тем более 20 раз в день? приведи хоть один пример?

вообще история изменения при НОРМАЛЬНОЙ разработке нужна только "на всякий случай" и ни более... Гораздо важнее это защита изменений при совместном редактировании, в 1с реализация на 100% позволяет защитить код, а вот в GIT нет такой защиты, ибо при мердже можно затереть чужое...

(202) зачем при мердже чужое затирать? смотри что менял и аккуратно делай.

(197) Идеальная причёска — это лысина?

(202) как ты можешь затереть чужое, если коммиты независимы?

(196) "В гите сравнил за секунду и не обязательно машинка рабочая с nvme, чтобы была. Просто на сайте гита мне показал изменения за пару секунд. Это касатеся не только изменений годовой давности." - Дальше что было?

(196) "Вот нужно понять как за последний месяц менялся определенный модуль" - когда приходят обновления вендера ты тоже сидишь смотришь как менялись модули??? Или у вас настолько пахнущий код что без этого никак?

(203) (205)

была процедура
Процедура СделатьВсе()
  а=10+1;
КонецПроцедуры

два разработчика поменяли на

Процедура СделатьВсе()
  Б=43;
КонецПроцедуры

и

Процедура СделатьВсе()
  ха=0+1;
  к=32;
КонецПроцедуры


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

(208) а в 1с второй не может затереть?

(209) в 1с вначале одно обновление затем второе - что логично

(210) и второй сцука будет думать чо он там заливает.

(208) ну если натягивать сову на глобус то можно и не такое придумать.

Чет вы раздули проблему. Есть опыт, где 3 команды каждая по 5 человек кодят ОЧЕНЬ АКТИВНО в рамках одного хранилища. Прям каких-то заморочек лютых никогда не было.

Проблема которую описал в (0) автор решается просто. Первый сохранил в СФ свою версию. Отпустил модуль без своих правок. Второй взял модуль и БЫСТРО внес свои правки с сохранением в хран (ведь в (0) написано ,что правки срочные и быстрые). Далее первый захватывает опять модуль и восстанавливает свои доработки из сохраненного СФка. Продолжает работу.

А на счет Гита, соглашусь с "vde69" ... это полнейшая хрень.

(213) Такое пишут когда 4 команды по одному человеку и все без мозгов и опыта, зато ютюб инстаграм смотрели, а там - гид.

(215) Ты прям маэстро написать так, что я уже  минут 10 понять не могу - ты "обосрал" или "согласился"

(216) Всё просто, есть старая школа, с опытом более 15 лет и новая, которая начинает на западный манер, а там гит, сонар, трансгендеры ....

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

Заказчики ведутся на эту дичь, которая дает гарантию околонулевую, и по сути это подстегивает других скатываться в это дно. Нук а чего, кодинг 10 часов,+сонар +тестирование 15. Нормально же на пусто месте +50%

(213) первый захватил и не отвечает сразу на сообщение второго и?

(217) дада
8-ка тоже трансгендеры тогда после 77
где не то что гита даже хранилища не было

(220) Воу-воу, полехче!

Для удобства работы с хранилищем конфигурации 1С мы в одной команде научились создавать болванки объектов каждого типа:
Справочник1, Справочник2...
Обработка1, Обработка2...

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

(213) А ещё можно выстроить схему с несколькими хранилищами и перезалитием конфы.

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

Файл обновления всегда целиковый CF и он делается из хранилища стейджа.
Конфа стейджа обновляется из нескольких dev. Ну это уже пошёл devops

(222) (223) А может просто перейти на гит?
Вместо подобных извратов

(224) Ещё раз, гит не решает вообще никаких проблем, вы релаьно тупо берет текст закидываете в гит далее качайте фремворк чтобы глянуть чего там и потмо мержите, это етсь в 1с - накуй гит?

(221) Привел прямую аналогию
Что в данном случае всего лишь столкнулись консерваторы с прогрессистами
Уже было с FoxPro > 1C 7.7 > 1C 8 ОФ > 1С 8 клиент-сервер > 1C УФ

(225) ты почитай про гит
простые случаи меджа он сам
для сложных да разрабы EDT много пилили и продолжают пилить

и да EDT кривая и прожорливая поделка
но свою задачу она с глюками но исполняет

(227) Не только читал и пользовал, в 1С это не надо. едт блювотна.

(224) Вы думаете, это просто?

(230) Достаточно легко
Вопрос пары дней

(231) А вот профессионалы говорят, что ощущения смешанные. Есть плюсы и минусы.

(232) Ни разу не было описано веского случая в пользу гит или тестирования - т.е. просто игрушки для "чудил".

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

Все плюшки эклипса — тоже плюс.

Сонар.

Но есть и минусы. Тормоза, выгрузки-загрузки, rebase...

(234) В других языках это плюс в 1с это убоость. Про редактирование общего модуля писали выше. Та кили иначе кто то первый.

в git lfs добавили блокировки файлов для желающих
хотя имхо это ненужная хрень убивающая идею децентрализованной системы

еще раз:

1. GIT - подходит когда пилят огромного монстра большой толпой и релизят редко (раз в месяц), для оперативной работы GIT вообще не подходит, по сколько сборка CF очень долгая и эффективность МЕЛКИХ доработок падает почти до нуля

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

3. ETD - сделана исключительно для мобильного приложения (ну и немножко для самой 1с, для типовых конф), а для 99% компаний простых она не нужна...

(237) 1. Нет. Для мелких доработок тоже подходит. "Сборка cf" долгая только первый раз.
2. Когда разработчиков много или пилят один огромный модуль с хранилищем наступает упс.
3. Имхо EDT в глаза не видели. Имхо как и МП/МК ибо для их разработки EDT не нужна.

И Конфигуратор и EDT это всего навсего два разных инструмента
Как и Хранилище и GIT всего два разных инструмента

И в некоторых случаях лучше одно, в некоторых другое

Было бы идеально если в Конфигуратор добавили работу с GIT
А в EDT работу с хранилищем напрямую

(234) в хранилище тоже можно нескольким редактировать - просто не нужно захватывать, и вести разработку в конфигурации не подключенной к хранилищу

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

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

(236) "
236 - 31.03.23 - 22:40
в git lfs добавили блокировки файлов для желающих" идут по пути 1с, скоро изобретут обновление .

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

(244) >>>веду к примеру 5+ задач.

у тебя 5 мышек? как ты ведешь сразу все 5 задач? по моему это бред....

кто мешает взять 1 задачку и ее сделать от начала и до конца, положить ее в хранилище и только потом приступать ко второй задачи?

(245)  Ок. Ты сделал и дальше не можешь ее отправить в продакт, так как заказчику нужно подумать. Или данные для реализации нужно исправить и тоже ждешь. И т.п. Реально разрешает руководство сидеть без дела это время?

(246) для этого есть тестовый контур, ты спокойно кладешь на тестирование и все...

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

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

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

(248) если задача на паузе ее не нужно начинать делать

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

плавали знаем
гит же просто в одном репозитории держит ветки задач-фич, и если что сливаешь с мастером-релизом

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

(251) если при тестировании не выловили хитрых багов это не значит, что надо что-то останавливать и кстати это означает, что доработка выполнена и обязана быть помещена в продакшен и ее уже не нужно отслеживать в списке актуальных задач, все проблемы которые возникают после приемки - это НОВЫЕ задачи, и решать их нужно в порядке устанавливаемым РП, например не обязательно отдавать баг тому, кто разрабатывал этот функционал а можно отдать другому, и по этому "я веду 10 параллельных разработок" для меня не понятно.

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

Ну а полный стек задач - это удел руководителей....

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

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

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

(254) причем тут фикси?
речь про большую разработку (даже по одному проекту для одного клиента-заказчика) с кучей аналитиков-разработчиков
где задач множество

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

И да.
Самый-самый изврат и недостаток хранилища конфигурации по сравнению с GIT

Это что нельзя туда произвольные файлы закидывать

Например внешние обработки!

(254) бывает и не такое

(200) Аж прям любопытно стало. хранилище - к нему подключено 4 информационные базы 4 аффилированных компаний на базе БП 3.0. Работают 5 моих программистов и 4 программиста заказчика. За год с 01.04.2022 по 31.03.2023 внесли 569 изменений в хранилище.
Включая ежемесячное обновление БП на текущий релиз.

(196) Я не очень понимаю зачем мне 20 раз в день сравнивать изменения годовалой давности.
Но иногда действительно возникает потребность сравнить что было год назад и сейчас.
один из наиболее проблемных модулей - УчетТоваров - я вот сейчас используя выборочное сравнение модуля получил сравнение текущего состояния модуля с ним же годовой давности - это у меня заняло 5-8 секунд.

ЧЯДНТ?

З.Ы. Может вы просто двойным щелчком пользуетесь (там тогда целиком версия сравнивается - и это действительно по 30-40 минут занимает) - вместо контекстного меню с выборочным сравнением модуля?

(259) Я не про отдельный объект же пишу. Мне нужно оперативно понять ВСЕ изменения по активности в рамках задачки. В Гите удобно, в 1С нет.

(260) я конечно не эксперт, но что ты там оперативно начал понимать, если у тебя 10 прогов, которые выдают 1200-1400 часов в месяц, или 24-28к часов в год? Вот просто интересно

(261) сорян, не на то умножил.

14,5к-16к в год часов разработки

(261)(262) Я про удобство пишу. При чем здесь количество программистов?

(263) тз в (0) подразумевает 10 человек.

Чо ты там смотришь по 20 раз на дню? Может и мне надо, хотя я так лично ничего не придумат, либо в базе 50 часов разработки лежит за год и тебе надо проанализировать что-то, но вероятность такого слбытия 0, а

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

А как в гноилище мерджить, о какой совместной разрабоке вы тут говорите?

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

(260)[В Гите удобно, в 1С нет.]
мы в курсе
ведение крупные проектов в Хранилище требует определенных усилий, технологии тебе описали многократно, смысл дальнейшего жевания соплей в топике какой ?

(260) так выгружай в гит исходники 1С и там смотри

у коллег (котлинщики) наблюдаю такую тему, что в команде 10+ разрабов, прекрасно живут в гите, code review, все дела.
когда пора деплоить задачку, в мерж реквесте должно быть n одобрений от коллег в код ревью, задача оттестирована, подлиты все последние коммиты из мастер-ветки.
разве что задачки надо делить на подзадачки, чтобы полпроекта не переписывать в одном мерж реквесте и коллегам не было больно это смотреть.
по сравнению с хоронилищем - все гораздо легче, особенно если умеешь в гит в командной строке.
работал в хоронилище с лохматых годов, с 2009го кажется.
кто бы что ни говорил тут, оно отваливается, это нередкий баг.
какие-то доработки теряются, редкий баг, но он есть.
удобство в стиле конфигуратора - выгрузки cf, чтобы что-то сравнивать, "ой, а отпусти-ка корень, мне тут справочник/обработку надо добавить".
это типа глючный SVN с одним возможным клиентом, на который 1С накладывает сверху трех-XL-ный.
естественно, все к нему привыкли уже и процессы отлажены, а с git'ом в 1С надо сношаться.

(270)
> кто бы что ни говорил тут, оно отваливается, это нередкий баг.
> какие-то доработки теряются, редкий баг, но он есть.
Давно работаю с хранилищем с большими объеми конф и коммитов, не сталкивался с такими проблемами

(270) > все гораздо легче, особенно если умеешь в гит в командной строке.
а какие сложности если из IDE?

(271) значит у нас его не умели готовить ))
(272) никаких, у меня скорее всего просто привычка - когда переходил из 1С на другой язык, пришлось учить работу в терминале, прочитал 2 книжки - коммандная строка Linux и git для профессионалов. в книжке вся работа с гитом из командной строки была.

(273) когда ты переходишь из храна к гиту, то в гите у тебя все - текст. Если сравнялка 1сная внутренняя хоть и оперирует текстом, но как-то там под капотом умеет все это маппить на метаданные, то просто через командную строчку с гитом вот так вот взять начать также мержить, как ты это делаешь в хранилище (в два клика) - уже не получится. А если конфа не адаптирована под упр.приложение, то там еще и костылей надо сверху поставить. Приблизился к такому же удобной работе с гитом как с хранилищем - это едт, когда ты мержишь через нее. Это правда удобно. Но в ней пока еще не так удобно работать, как в конфигураторе. Слишком и высокий порог входа, да вся прелесть с проверками на плагинах, пока для основной массы особо не дает вау-эффекта, т.к. передовые типовые сами на этих же проверках валятся. В целом, гит - это не аналог хранилища, просто так - на нем развалить конфу можно особо не парясь. На хранилище у тебя это не получится. Однако, как уже говорили, скорость гита - космическая.

(274) то, что вы описали - это последствия решений 1С при проектировании платформы и формата хранения данных в cf.
кто ж им мешал сразу удобную работу с git в конфигураторе? в совершенном коде кстати было уже озвучено, что "самые дорогие ошибки в ПО - это ошибки проектирования". это мы и видим на практике. сколько лет уже не могут нормально сделать EDT + git?

(275) я подозреваю, что гита ещё не было, когда вышла платформа

(276) Ты абсолютно прав
Сервис для совместной разработки и хостинга ИТ-проектов Github был основан в апреле 2008 года программистами Крисом Ванстрасом (Chris Wanstrath), Томом Престон-Вернером (Thomas Preston-Werner) и Пи Джей Хайеттом (PJ Hyett).

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

Хехе, я пришел на месяц раньше в отрасль

(277) Это Сервис на основе системы контроля версий. А сама система контроля в 2005 выпущена. Под лицензией GNU

(278) Так и представил как я, вместо фильма за всю ночь выгружаю и утягиваю 1Ску с гитхаба ;-)

(218) Как с языка снял. Много народу пытаются пропихнуть GIT там где он совершенно не нужен.  также часто вместе с этим внедряют бесполезный SonarCube +Jira. Это для меня сразу показатель особой одаренности.

От этого усложняется разработка, больше времени тратиться на всякие свисто-пляски. Эффективность отдела разработки сильно падает.

Чтобы это все админить уходят ресурсы одного человека.

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

(280) А SonarCube и Jira чем провинились?

(280) автотесты тоже на помойку, бухша тётя Клава сама оборотку сверит после обновления и перепроведения.

(282) не видел ни одного теста который это делает

(280) Еще забыл.

Также есть уникальные люди которые внедряют СППР , но не понимают что это очень узкоспециализрованное решение которое нужно на 1 из 100 проектов

(283) а ты каким таск-трекером пользуешься?

(283) к (284)

(285)Комментарием в коде

(287) а когда надо править ужен правленый код, что делаешь?
если разные люди правят по разным задачам?

(288) В чем сложность такой задачи , можно пояснить ?  Иногда можно перетереть старый код если не нужен и устарел, иногда можно оставить и добавить комментарий.

(289) Ну как пример тебе, чтобы комментариев не было больше чем кода, в гите через коммиты делают описание изменений.

(290) Разработчик зашел в модуль сразу видит комментарии, зачем ему искать их где то в GITе ?

(290) + в хранилище при помещении тоже комменты  можно добавлять

(286) Никаким, надобности нету. По тестированию вообще считаю надуманной проблему, то что ты написал никто не делает.

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

(291) Это бест-практика из мира для взрослых: когда коммит помечается таском из трекера. Ну типа, аналитики в конфлюэнсе подробно расписал какое-то ЧТЗ, нарезал его тонко. В жире он создает таски и маппит на какие-то пункт в кофлюэнсе. Разраб берет таск, кодит, коммитит и метит - это коммит по этому таску. И там дальше у тебя в какой-то веб-морде сразу видно - вот коммит, вот пруф на таск в жиру, оттуда в конф. И так можно быстро подымать контекст, кто когда почему для кого - что-то комитил.

(294) Это понятно. Но по факту я могу также взять номер задачи из комменнта и найти в системе учета задач по номеру задачи всю информацию ,что мне нужно по задаче

(294) Зачем это всё, если ЧТЗ можно комментом в самом модуле написать?

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

(296) см. 295

(297) Тут большинство сидят в отделах до 10ти. А ты описываешь 0.001% Программистов с дикой текучкой где этот самый контекст нужен. Хотя чем олн там поможет не ясно - увидел косяк увидел что закосячил Вася 2 года назад - что с этой информацией делать?

А теперь привиди - какойто тест из своей "зэбест практик" который завалился.

(298) да, это практика когда много народа на проекте навалено. Когда вас два землекопа, вы сами себе и постановщики и аналитики и т.д., то вы даже не настроите все это, это уже оверскил. Тут вроде про то - зачем это надо.

(297) Ну если завалился код, и так видно место где он упал в конфигураторе - зачем здесь доп.прослойка? также видно в комменте в конфе номер задачи - также понятно для чего это сделано. Сэкономить 30 секунд чтобы найти в системе задач нужную задачу?

(300) а если строка была создана одной задачей, потом в ней ошибка исправлялась другой и потом ещё дорабатывалась третьей?

(301) А из комментов этого разве не видно ?

Кроме того все равно придется лезть в конфигуратор в большинстве случаев , так как падать может в одном месте. А причина падения кода -вообще в другом месте.

(280) я разрабатываю сейчас на голанге, там есть свой линтер, называется golangci-lint, он сканирует уязвимости, куски кода с большой цикломатической сложностью. очень крутой инструмент.
если запустить со строгим конфигом - много чего показать может, хотя есть ложные срабатывания.
гораздо удобнее, чем типовой процесс разработки в конфигураторе. уж поверьте мне, 1С разработчику с 10+ лет опыта с разработкой сложных нетиповых конфигураций (куда не каждого 1Сника еще и позвали из-за плохого знания клиент-серверного взаимодействия).
(302) кек. коммент можно пейсать, а можно и нет.
причем более того, можно историю глянуть что с этим комментарием делали.
у нас в конторе, где очень много программистов, если в коммите нету номера задачки, этот коммит не принимается в gitlab'е, который является origin'ом для git'а в проекте.
дело в обязательности, любой инструмент нахой не нужен, если нет силы заставляющей его использовать.

(302) Т.е.для одной строки кода у тебя здесь будет три комментария? И потом ещё для последующих доработок

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

(306) для ликбеза рекомендую погуглить техники тестирования. Например граничные значения, классы эквивалентности. То что ты не видел такого, говорит лишь о масштабе систем, с которыми ты работал

(307) Клоунов с инфостарта собери и гуглите сколько влезет - может чего полезного сделайте.

Какой масштаб у ерп ут или зп? какой масштаб у доработок? Я сужу о полезности инструмента по изложенному и личному опыту. Пример ты тоже не привел что говорит о моей правоте.

(304) Понятно, у нас в конторе разработчики простое пишут комментарии. Все работает как по маслу

(308) >Какой масштаб у ерп ут или зп?

Ты не знаешь что при разработке типовых уже давно используется EDT и Git?

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

(310) Если судить по количеству обновлений в месяц - очень хорошо видна эффективность подобного подхода.

(308) а для тебя конфигурация это и есть система? Клоуны с инфостарта это люди трудами которых ты пользуешься. Некоторые из них ушли работать в фирму 1с

(313) 99% текста про гит и тестирование - полная куета, я этим не пользуюсь в рамках 1С.

(314) можешь пояснить, кого интересует - чем ты пользуешься в рамках 1С, а чем - нет?

сейчас на проекте собралась очередь из трех на один модуль, хранилище...

(316) случайно не МодификацияКонфигурацииПереопределяемый ? :)

(316) Юзайте https://infostart.ru/1c/articles/1443756/

(316) каждому раз-рабу по собственному пофигуратору, копии базы и собственному хренилищу :)

(318) +1

(319) Кстати, хороший рабочий вариант. Просто когда первый раз по нему идешь - слишком много возни. С гитом то попроще такие вещи делать, когда ты весь в гите.

(320) Кажется, СППР уменьшает количество возни https://its.1c.ru/db/sppr2doc#content:35:hdoc

(321) да, при условии что вся контора сидит на СППР.

(61) все написанное корректно
Всегда можно договорится или подождать пока метаданные заняты другими
Иначе тестирование не работает. Оно и так тяжело осуществимо. А если задачи пересекаются, то это практически невозможно.
Уж не знаю что такое эдакое нужно активно пилить в 10 прогеров.

(320) такое можно автоматизировать скриптами с использованием онескрипт или типа того, обновлятор 1с, и т.п.

(319)
дык на ERP по другому не получается
но вместо отдельных хранилищ - индивидуальные ОМ

(325) для колхозников-чо такое ОМ?

(326) ОМ - общий модуль жы

(325) да-да
индивидуальные по фамилие или по задаче?