search

1C-Company / 1c-edt-issues

Пространство для пожеланий и обсуждения ошибок 1C:Enterprise Development Tools
https://edt.1c.ru/
138 stars 9 forks source link

Развитие шаблонов кода #147

Open Desar14 opened 2 years ago

Desar14 commented 2 years ago

Описание проблемы

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

Описание решения проблемы

Добавить в конструкции шаблона имя текущей ветки git, а также, по возможности - возможность использовать только части этого имени (например при feature/4414 использовать только 4414 в шаблоне). Либо, строковые функции, как альтернативный вариант.

Дополнительная информация

No response

nixel2007 commented 2 years ago

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

Desar14 commented 2 years ago

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

к сожалению, внутренний стандарт. и в коде, и в комментарии к коммиту

EvilBeaver commented 2 years ago

Риторический вопрос: Зачем работать в организации, в которой есть дурацкие стандарты? А если по делу: покажите им как работает git blame с привязкой прямо к задаче в джире и стандарт тут же упразднят

Desar14 commented 2 years ago

Риторический вопрос: Зачем работать в организации, в которой есть дурацкие стандарты? А если по делу: покажите им как работает git blame с привязкой прямо к задаче в джире и стандарт тут же упразднят

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

NikitaMikhaylovSB commented 2 years ago

Сама компания может вести разработку с использование git+edt. Но итоговый результата заказчик требует в виде cf. Как туда блейм передать и кому? Ну и да: обновление средствами конфигуратора блейм не поможет, а делать его может другой подрядчик...

nixel2007 commented 2 years ago

Зачем заказчику blame?

NikitaMikhaylovSB commented 2 years ago

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

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

EvilBeaver commented 2 years ago

@NikitaMikhaylovSB я пробовал сопровождать код который покрывали авторскими комментариями, то что они помогают - это фикция (на мой взгляд) Эти комментарии лгут, не обновляются, спутываются между собой и т.п.

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

NikitaMikhaylovSB commented 2 years ago

@EvilBeaver есть разные требования к оформлению кода. То, что конкретно у вас это редкость - для нас совершенно обыденная вещь. (Это как правильно ударение в слово Сопло поставить)

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

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

EvilBeaver commented 2 years ago

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