Есть ли какие-либо проблемы или соображения, связанные с поднятием заявки с обратной стороны обзора, а не с ее провалом?
Не по своей сути. Например, реализация текущего изменения, возможно, обнаружила проблему, которая уже существовала, но не была известна / очевидна до сих пор. Отказ от билета был бы несправедливым, поскольку вы потерпели бы неудачу из-за чего-то, не связанного с фактически описанной задачей.
в обзоре мы обнаруживаем функцию
Тем не менее, я предполагаю, что эта функция добавлена текущим изменением. В этом случае билет должен быть не пройден, так как код не прошел тест на запах.
Где бы вы нарисовали линию, если не там, где вы ее уже нарисовали? Вы явно не думаете, что этот код достаточно чистый, чтобы оставаться в кодовой базе в его текущей форме; так почему бы вам тогда подумать о выдаче билета?
Сбой проверки кода, чтобы билет не закрывался в этом спринте, и мы немного пострадали от морали, потому что мы не можем выдать билет.
Мне кажется, что вы косвенно утверждаете, что пытаетесь дать этому билету пропуск, чтобы повысить моральный дух команды, а не улучшить качество кодовой базы.
Если это так, то у вас смешанные приоритеты. Стандарт чистого кода не следует менять просто потому, что он делает команду счастливее. Правильность и чистота кода не зависят от настроения команды.
Рефакторинг - это небольшая часть работы, которая будет выполнена в следующем спринте (или даже до того, как он начнется) в виде крошечной истории с половиной баллов.
Если реализация исходного тикета вызвала запах кода, то к нему следует обратиться в оригинальном тикете. Вы должны создавать новый билет только в том случае, если запах кода нельзя напрямую отнести к оригинальному билету (например, сценарий «соломинка, которая сломала спину верблюда»).
Ресурсы, которые я могу найти и которые читают подробные обзоры кодов, обычно составляют 100% или ничего, но я считаю, что это обычно нереально.
Проход / неудача по своей сути является двоичным состоянием , которое по своей сути является всем или ничем.
Я думаю, что здесь вы имеете в виду больше то, что вы интерпретируете обзоры кода как требующие идеального кода или иным образом его не выполняющие, а это не так.
Код не должен быть безупречным, он должен просто соответствовать разумным стандартам чистоты, применяемым вашей командой / компанией. Приверженность этому стандарту является бинарным выбором: он придерживается (проходит) или нет (не проходит).
Исходя из вашего описания проблемы, ясно, что вы не думаете, что это соответствует ожидаемому стандарту кода, и поэтому его не следует передавать по скрытым причинам, таким как командный дух.
В противном случае задача соответствует определению выполненного.
Если бы «он выполнял свою работу» был лучшим эталоном качества кода, то нам не пришлось бы изобретать принцип чистого кода и хорошую практику для начала - компилятор и модульное тестирование уже были бы нашим автоматическим процессом проверки и Вам не понадобятся обзоры кода или аргументы стиля.