Кто и как сохраняет комментарии ("номера задач") для объектов метаданных при разработке?

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

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

(0) git, как для кода, так и метаданных

все добавленные объекты метаданных отмечаются спец. подсистемой "Добавлено"
все измененные объекты метаданных отмечаются спец. подсистемой "Изменено".
При необходимости в модуле менеджера комментарий какие реквизиты добавлены, изменены и т.п. с номерами задач

(1) Это конечно вариант, но часто EDT и Git нет

(2) Вот это уже интересно
Может и готовый регламент разработки есть?
Где описано это и возможно что еще полезное?
Можете поделиться?

(2) Я теоретически думал создать служебную подсистему
И у нее фигачить на каждую задачу свою подчиненную подсистему по номеру задачи
Но вопрос как платформа 1С и Конфигуратор переварят тысячи добавленных подчиненных подсистем :)

регламентом поделить не могу, ибо собственность франча))
Но т.к. я его писал, то:
1. Создаем подсистему именем франча (или организации если в штате) не включаемую в интерфейс
1.1 создаем подчиненные подсистемы не включаемые в интерфейс:
    "Добавлено" - ей отмечаем все объекты метаданных которые добавили.
    "Изменено" - ей отмечаем все объекты, которые типовые и которые мы изменили

2. Все добавленные объекты метаданных (в т.ч. формы и реквизиты) добавляются обязательно с префиксом (ЗА ИСКЛЮЧЕНИЕМ тех случаев, когда для отработки штатных функций и т.п. требуется нормальное название. В этом случае обязательно пояснение в комментарии что добавлено именно нами)
В модуле менеджера комментарий по какой задаче/зачем и когда добавлен объект, реквизит....

3. Доработки проверки заполнения, копирования, передзаписью, послезаписи предпочтительно через подписки на события (с обязательным комментарием в модуле менеджера что для объекта есть подписка на событие, ее название и для чего)

4. Все доработки в коде оформляются комментариями вида:
// {## ФИО, номер задачи, дата
// при необходимости почему именно так

// БЫЛО
// если меняем то тут закомментированнй исходник

// СТАЛО

// }## ФИО, номер задачи, дата

5. Доработки форм ПРОГРАММНЫЕ (исключения обговариваются заранее). Для ЕРП и ее "обрезков" заводим свой модуль доработок формы там точки входа из типовых процедур и пишем все там. Для бухии и ЗУП - есть нюансы.
6. запросы в цикле - зло
7. в пакетных запросах фильтры задавать как можно ранее
8. использование фильтра не в параметрах виртуальной таблицы, а в секции "ГДЕ" карается через матумбу
9. в общем случае вместо вложенных запросов использовать пакет запросов и временные таблицы
11. если в запросах идет выборка из полей составного типа а мы знаем что выбираем конкретный тип - использовать ВЫРАЗИТЬ(
10. получение реквизитов объектов через "." ИЗ ССЫЛОК карается через матумбу. Использовать "ОбщегоНазначения.ЗначениеРеквизитаОбъекта(" если нужен один реквизит и "ОбщегоНазначения.ЗначенияРеквизитовОбъекта(" если нужно несколько
11. конфигурация должна проходить синтаксический контроль (по кр. мере в части ваших дописок)



ну вот как-то так навскидку

(6) п.10 даже в типовых не соблюдается строго ))

(6) п.5 нюансы есть и для ERP
когда точек входа в типовых формах нет
и даже типовых обработчиков событий форм нет бывает ))

(7) Надо стремиться все делать отлично. Херня сама получится... (с)

(6) по п.3 категорически не согласен!
лишние подписки это зло, если есть типовые механизмы
а уж последовательность вызова подписок это гм

(8) Там же не зря написано про исключения )))

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

(0) в хранилище коментарий

в тексте или метаданных это только вредит, вот вижу я в коде:

# Вася 01/01/2000 задача 4568

и чего это дает?

(13) Это дает, как минимум, понимание о том, что здесь был Вася.
А если у конторы есть система типа жира или им подобная - то даже можно будет посмотреть зачем он там был

(14) а если доработку вели все кому не лень? и это номер задачи какого-то франча?

(6) Даже если документ полностью нетиповой, т.е. добавлен вами, типа Франч_НовыйДокумент, всё равно все его реквизиты с префиксом? Не избыточно ли?
А если документ добавили, а потом изменяли, то он будет в двух служебных подсистемах? Или в "Изменено" только типовые объекты?

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

(0) комментария в истории хранилища достаточно.

новые объекты помечать + в начале комментария,
удаленные объекты -
измененные объекты //

номера задач через # например

еще есть кроме комментариев метки к каждой записи в истории хранилища. по ним даже фильтр работает

(16) если объект полностью нетиповой достаточно префикса в объекте: Франч_НовыйДокумент. В его реквизитах, формах, макетах префикс не нужен.
А если объект типовой - то в каждом его добавленном реквизите/макете/форме нужен префикс.
В подсистему изменено попадают только ТИПОВЫЕ измененные объекты. Собственно она нужна для того, чтобы посмотреть чего наменяли из типового

(15) В самом худшем случае ты просто будешь видеть что это кусок измененного/добавленного кода. А если ты знаешь франча и с ним норм. отношения - уже можно посмотреть что за задача была.
А вообще в норм. конторах своя внутренняя нумерация задач. И люди работающие с ними живут именно с этой нумерацией. Мы же не о ларьке говорим?

(20) Как связать номера задач с кто, что, зачем и почему - это отдельный вопрос, за рамками темы
Бывает что несколько задач связанных - фактически одна и надо одновременно их пилить/переносить

Сабж возник из командной разработки с несколькими хранилищами и отдельными базами вне хранилищ
Когда EDT и Git нет

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

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

(21)+ В Конфигураторе есть фильтр по подсистемам, очень удобно
Но прокатит ли (5) ?

хуже, когда
//Вася ++ #
// тут хренова туча строк коммента
тут Вася что-то добавил
//Вася -- #

куча комментов засоряет модули

+23 проходили такое, смотреть в модули - глаза на выкате )

(23) Да, эта проблема только через Git решается

(21) Разве в истории не видно какие объекты закоммитил?

(20) почему сама 1с в типовых не оставляет в коде номера тикетов?

Да по тому как это не нужно и в последствии не реально использовать.


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

(25) а как гит избавляет от таких комментариев?

если их не писать, то как накатывать новые релизы?

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


>почему сама 1с в типовых не оставляет в коде номера тикетов?
Откройте насквозь типовую бухгалтерию и гляньте, например, свойства справочника "БанковскиеКартыКонтрагентов". В комментарии объекта вы увидите вот это:
"АПК:1206 Нестандартная длина кода связана с форматом номеров платежных карт"

Это не тикет оставшийся?

(29) это скорее комментарий

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

(31) Это невозможно практически
Модулей и обработчиков нет часто

(30) что-то мне подсказывает, что 1206 это все-таки не номер комментария а скорее номер тикета.
Поищите в бухии "АПК:" - там много всего разного.

(27) Объединять и/или удалять старые тикеты согласен
Удалять уже ненужный закомментированный код в типовых
И объединять/группировать старые тикеты по смыслу, но чтобы метки/комментарии остались, для облегчения поднятия версии типовой

В своих нетленках можно сразу удалять старый, да

(31) Мы же не о ларьке с новой печатной формой и внешним отчетом говорим. Даже в более/менее "маленьком" внедрении ваш совет, к сожалению, не применим.

лучше комментарии НИКОГДА не удалять.
я находил задачи по номеру в коде и через 5-7 лет и это пригождалось чтобы доказать спорщикам - что и почему было сделано.
давно не дискетки используем для хранения - так что что экономить на тексте.
а вот избыточные комментарии - зло - одной строчки краткого пояснения в начале логического блока кода хватит

(29) АПК - конфигурация "автоматическая проверка конфигураций", содержит в себе шаблоны проверки кода на стандарты 1с. а АПК:1206 маркер указывает ей, что процедуру ниже этого комментария проверять не нужно, и тот кто ее написал отошёл от этого стандарта сознательно

//{Фирма
//ФИО
//Дата
//Задача (если для решения задачи надо править код в нескольких местах название должно быть строго одинаково)
//Примечание
//{1С} — если изменение в расширении меняет код из 1С, чтобы при обновлении найти в расширении места которые требуют проверки

//{Убрано
...
//Убрано}

//{Добавлено
...
//Добавлено}
//Фирма}

(38) Жёстка...
Закомментированный ад

(39) Что именно смущает?

(40) Вместо программирования люди занимаются комментированием. Внимание отвлекается, распыляется. Бюрократия, сонар-диктатура. Мерзкое местечко...

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

(41) Забить эти строчки 1-2 минуты. Зато когда через пять лет открываешь код — сильно помогает.

(43) через 5 лет глобоко пофигу зачем этот код существует...

(42) Тут согласен.

Но тут по упрощенному варианту
//{Убрано ФИО Дата
...
//Убрано}

//{Добавлено ФИО Дата
...
//Добавлено}

(45) не хватает главного тега
//{Работает "мамой клянусь"

а вот этот дрочь - убрано добавлено и как правильно сказали рекурсивно убран и добавлен, убран и добавлен... не нужен

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

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

(6) а шо расширениями не пользуетесь?

(6) 1. Создаем подсистему именем франча

...ну да видел я такие конфы ...после 10 франчей...

(42) +1

комментарии, которые комментируют другие комментарии, которые написаны что-бы понять что в предыдущих комментариях))

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

(51) Никогда состав плана обмена или определяемый тип не менял?

(50) часть комментария которая
// БЫЛО

и закомментированный старый код

касается ТОЛЬКО И ИСКЛЮЧИТЕЛЬНО типового кода.
Если правится что-то не типовое, то старый код оставлять не надо.
Если правится дописка - то старый код оставлять не надо.

(48) 1. Не всегда все можно сделать расширениями, особенно где старая платформа.
2. чисто мое ИМХО - концы с расширениями искать сложнее.
3. чисто мое ИМХО - расширение имеет право на существование в 2х случаях:
- надо что-то исправить не снимая конфу с "замка" и БЕЗ добавления реквизитов метаданных
- срочно что-то надо исправить в проде. Но в этом случае все доработки из расширения должны быть перенесены в конфу и прод обновлен нормально, а расширение убрано.

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

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

когда нет контроля и гарантий - использовать такой механизм - это дополнительные ненужные риски

(55) у расширений есть свое хранилище и их тоже можно версионировать и обновлять через командную строку/сборочную линию. оставьте ваши страхи в 2018 году.

(56)  Тут речь не про хранилище, а про то как искать почему что-то работает не так как в коде прописано при наличии хотя бы от 5 расширений. А если учесть что почему-то не всегда корректно отрабатывает &ИзменениеИКонтроль - то вообще.

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

(57) если проект настолько большой, то в нем должен быть выделенный архитектор, который мерджит эти изменения?
стек замера производительности показывает все расширения, что там искать?
про &ИзменениеИКонтроль в платформе были глюки с отступами тексте в ранних 8.3.* , но вроде их давно пофиксили.

(58) Естественно должен. Но одно дело мержить несколько хранилищ конфигурации, другое дело к ним еще и хранилища расширений.
И, главное, смысл? Какой выигрыш дает этот гемморой?

>про &ИзменениеИКонтроль в платформе были глюки с отступами тексте в ранних 8.3.* , но вроде их давно пофиксили.

В теории - наверное. А вот на практике - БЯДА.

(56) я могу сравнить конфигурацию поставщика с расширением? А с несколькими расширениями?

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

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