Существуют ли риски (с точки зрения поддержки продукта) для добавления поля OOTB, предназначенного для одной цели, к дополнительным рабочим элементам для новой (хотя и схожей) цели?
Поскольку у вас нетЯ не упомянул, какой тип проекта вы используете, здесь я поговорю с TFVC / Git об этих двух разных типах.
То, что вы затронули, это с точки зрения поддержки продукта , если ваш проектиспользуя тип Git, это добавленное поле Reviewed by было бы легко перепутать, чтобы выяснить, на какие метрики вам и вашей команде-разработчику нужно сосредоточиться.
На самом деле, Reviewed by необходим во время разработки.Только для проекта типа Git эта метрика интегрирована в политику ветки .Во время разработки разработчику и руководителям / администраторам проекта необходимо сосредоточиться только на обязательных / необязательных требованиях в Запросе на извлечение.Поскольку большинство разработчиков привыкли к PR, Reviewed by, поданный в WIT, будет легко проигнорирован, и, кроме того, это сделает отчет более неочищенным, так как этот показатель повторяется с Reviewed by option вPR.
Но, если вы используете TFVC, то, как вы знаете, PR проекта TFVC не существует.В настоящее время проверка кода является необходимым методом для повышения общего качества кода и снижения риска создания дополнительных ошибок.Поле Reviewed by может дать этому обзору больше прослеживаемых .
Вы можете добавить это поле в процесс, который используется проектом, над которым работает соответствующая команда.Затем установите это поле, как требуется, чтобы обеспечить строгое выполнение проверки кода.
Было бы лучше создать новое настраиваемое поле?
На самом деле, мы рекомендуемВы используете поле OOTB вместо настройки нового.