¿existen problemas o consideraciones inherentes con la obtención de un ticket de la parte posterior de una revisión, en lugar de fallarlo?
No inherentemente. Por ejemplo, la implementación del cambio actual puede haber desenterrado un problema que ya estaba allí, pero que no se conocía / aparecía hasta ahora. Fallar en el boleto sería injusto, ya que fallaría por algo no relacionado con la tarea realmente descrita.
en la revisión descubrimos una función
Sin embargo, supongo que la función aquí es algo que se agregó con el cambio actual. En este caso, el boleto debería fallar ya que el código no pasó la prueba de olfato.
¿Dónde dibujarías la línea, si no donde ya la dibujaste? Claramente, no cree que este código sea lo suficientemente limpio como para permanecer en el código base en su forma actual; Entonces, ¿por qué consideras dar un pase al boleto?
Falla la revisión del código, para que el ticket no se cierre en este sprint, y recibimos un pequeño golpe en la moral, porque no podemos pasar el ticket.
Me parece que estás argumentando indirectamente que estás tratando de darle a este boleto un pase para beneficiar la moral del equipo, en lugar de beneficiar la calidad del código base.
Si ese es el caso, entonces tienes tus prioridades mezcladas. El estándar de código limpio no debe modificarse simplemente porque hace más feliz al equipo. La corrección y limpieza del código no dependen del estado de ánimo del equipo.
El refactor es una pequeña pieza de trabajo, y se haría en el siguiente sprint (o incluso antes de que comience) como una pequeña historia de medio punto.
Si la implementación del ticket original causó el olor del código, entonces debe abordarse en el ticket original. Solo debe crear un nuevo ticket si el olor del código no se puede atribuir directamente al ticket original (por ejemplo, un escenario "de paja que rompió la espalda del camello").
Los recursos que puedo encontrar y que he leído las revisiones de los códigos de detalle son 100% o nada, por lo general, pero encuentro que generalmente no es realista.
Pasar / fallar es inherentemente un estado binario , que es inherentemente todo o nada.
A lo que te refieres aquí, creo, es más que interpretar que las revisiones de código requieren un código perfecto o que de lo contrario fallan, y ese no es el caso.
El código no debe estar inmaculado, simplemente debe cumplir con el nivel razonable de limpieza que emplea su equipo / empresa. La adhesión a ese estándar es una opción binaria: se adhiere (pasa) o no (falla).
Según su descripción del problema, está claro que no cree que esto se adhiera al estándar de código esperado y, por lo tanto, no se debe aprobar por razones ulteriores, como la moral del equipo.
De lo contrario, la tarea se ajusta a la definición de hecho.
Si "hace el trabajo" fue el mejor punto de referencia para la calidad del código, entonces no habríamos tenido que inventar el principio de código limpio y buenas prácticas para comenzar: el compilador y las pruebas de unidad ya serían nuestra automatización. revisa el proceso y no necesitarás revisiones de código ni argumentos de estilo.