¿Debería todo desarrollo, incluido el trabajo de refactorización, ir acompañado de un problema de seguimiento?

El debate: ¿Debería todo desarrollo, incluido el trabajo de refactorización, ir acompañado de un problema de seguimiento? (en nuestro caso, Jira)

El terreno común: nuestro objetivo principal es la calidad. Un producto que funcione, cada lanzamiento, es más importante que cualquier otra cosa. Nuestra base de código es antigua y faltan pruebas automatizadas; Estamos trabajando en esto, pero es un proyecto a largo plazo, necesitamos procesos provisionales.

Posición 1: El trabajo de refactorización debe rastrearse en Jira. Si obviamente no está relacionado con el cambio que está realizando, debe plantear otro problema. Si no lo hace, el trabajo pasa por alto la revisión y las pruebas y existe un riesgo para nuestro objetivo principal. Se ha argumentado que el cumplimiento de PCI (un objetivo de la empresa en un futuro próximo) requiere este nivel de seguimiento; No estoy en condiciones de decir que es verdadero o falso con ningún nivel de certeza.

Posición 2: la calidad del código es muy importante. Cuanto mejor sea (hasta cierto punto; un punto que no estamos cerca), es más probable que sigamos lanzando un producto que funcione. Cualquier cosa que ponga una barrera, por pequeña que sea, en el camino de la refactorización es un riesgo para nuestro objetivo principal. A menudo, el IDE hace el trabajo por usted, por lo que no es probable que salga mal de todos modos.

Se han realizado los siguientes casos:

¿Satisfacería ambas posiciones si un desarrollador escribe "Refactor" y los números de revisión relevantes en una tarjeta? Honestamente, esto parece que hará que todos estén igualmente infelices. Todavía pone un nivel de resistencia en la refactorización, pero no ofrece un seguimiento suficiente.

¿Qué pasa con tener problemas de Jira que abarcan todo y que cubren el trabajo de refactorización para una iteración? Sí, esto elimina la capa de resistencia del desarrollador, pero me temo que también elimina los beneficios de seguimiento de tener un problema con Jira. ¿Cómo puede obtener un control de calidad una idea clara de qué probar? Esto parece ser una solución política, mantener a todos tranquilos al agregar un proceso liviano pero en última instancia inútil.

Me parece que, dado que ambos lados del debate en última instancia quieren lo mismo, debería haber una solución que haga a todos genuinamente felices. No podemos haber sido las primeras personas en hacer esta pregunta, entonces, ¿qué experiencias han tenido otros en situaciones similares?

Quizás me estoy perdiendo algo aquí, pero ¿cómo crear una boleta para el trabajo que está haciendo que no está dentro del alcance de sus otras boletas es una 'capa de resistencia'?

¿Ha implementado recientemente el uso de un sistema de seguimiento de tickets? Si es así, siéntese y establezca sus reglas para usarlo y hágale saber al equipo que se espera que sigan estas reglas. Si esto incluye crear tickets de refactorización para este trabajo, que así sea. No puede hacer excepciones desde el principio o podría descarrilar todo el proceso que su equipo está tratando de configurar.

Si ha estado usando un sistema de seguimiento de tickets por un tiempo, entonces realmente no entiendo por qué esto sería una 'capa de resistencia'. Su equipo ya debería estar acostumbrado a que Jira abra y mire sus boletos y debería sentirse cómodo haciendo boletos.

Si desea mantener todos los esfuerzos de refactorización en un solo lugar, cree un boleto principal para esto y haga que su equipo realice tareas para el trabajo que están haciendo. Luego, el desarrollador tarda unos 5 segundos en realizar una nueva tarea para esto y puede registrar su tiempo en esa tarea.

Los gerentes de proyecto, los líderes de equipo y los desarrolladores necesitan saber cuánto tiempo se dedica al esfuerzo de refactorización. No quieres que se convierta en un agujero negro del tiempo. Tener los tickets hace que los desarrolladores sean responsables de su trabajo, al tiempo que proporciona a los gerentes y lidera un lugar para realizar un seguimiento de cuántas horas van al esfuerzo.

Idealmente si.

Cualquier cambio que realice en la base del código debe tener una razón detrás. Esto puede ser una solicitud del cliente, la más común / probable, o un elemento planteado internamente, como en su ejemplo de refactorización.

Esto significa que además de rastrear cuándo se realizó un cambio, puede vincular el conjunto de cambios a algo que explique por qué se realizó el cambio. ¿Por qué no pueden ser solo los comentarios del conjunto de cambios? Hay varias razones por las cuales esto podría no ser adecuado.

• No siempre hay una asignación 1: 1 entre elementos de trabajo y conjuntos de cambios; es posible que necesite varios conjuntos de ediciones para completar un elemento.
• Los comentarios del conjunto de cambios generalmente no son visibles para los que no son desarrolladores o es posible que deba adjuntar otra documentación al elemento de trabajo.

La refactorización del código, si bien es altamente deseable para mejorar la calidad, también es un riesgo inherente. Esto es especialmente cierto cuando se trata de código "básico" donde un solo error hará que todo el sistema se caiga y resolver un solo "problema" tendrá efectos secundarios (quizás imprevistos) en toda la aplicación.

Independientemente del tipo de código involucrado, cuando una refactorización no se limita al código para un problema específico (ticket), el control de calidad debe estar involucrado y conocer las partes de su base de código que se vieron afectadas. Tendrán que hacer una prueba de regresión completa en esas partes para asegurarse de que no se les escape nada. Y tendrán que hacerlo incluso, tal vez especialmente, si tiene un conjunto completo de pruebas unitarias que lo hagan sentir confiado sobre la refactorización. Las pruebas unitarias prueban mucho, pero también fallan mucho.

Entonces, si la calidad del código es importante, sí, debe haber la menor cantidad posible de barreras para mejorar el código. Pero no veo cómo crear una entrada para esto es una barrera. Simplemente garantiza que el control de calidad tenga la oportunidad de (im) probar la calidad del código y debe ser algo deseable, no algo visto como una obstrucción.

Creo que si no puede describir la refactorización más específicamente que la "refactorización", lo está haciendo mal. La refactorización debe tener un propósito y alcance definidos. El seguimiento de las tareas de refactorización por separado en JIRA no solo facilita la auditoría, la revisión y las pruebas, sino que también obliga a los refactoristas a centrar sus mentes en objetivos concretos ("eliminar una dependencia circular entre los módulos X e Y", por ejemplo) y simplemente conducirá a Mejor refactorización.

Por otro lado, si la refactorización es realmente simple, local y solo un subproducto de llevar a cabo una tarea diferente, no me molestaría en rastrearla en un boleto separado y solo documentarla en el boleto original de Taks, si puede tener un impacto en el trabajo de otras personas.

Sí, idealmente cada cambio que realice en el código debe estar asociado a un elemento JIRA y, por lo tanto, debe poder rastrearse. Como otros han señalado, debe poder identificar por qué se realizó un cambio determinado y con qué otros cambios está relacionado.

Está bien tener una refactorización de Epics a largo plazo en un proyecto heredado, también los tenemos en el nuestro. Sin embargo, debe esforzarse por enfocarlos en un área específica del código, con un propósito específico, de lo contrario es realmente difícil mantenerlo bajo control. Por ejemplo, "refactorizar módulos Foo y Bar para eliminar dependencias cíclicas", "refactorizar la jerarquía de clases A para eliminar duplicaciones y limpiar la jerarquía de herencia".

Cuando se trabaja en código heredado, con recursos limitados, uno debe priorizar las posibles formas de reducir la deuda técnica, para lograr el mejor retorno de la inversión posible. Por lo tanto, analizar posibles refactorizaciones, su importancia, riesgos, costos y beneficios debe hacerse de todos modos antes de comenzar el trabajo. Además, es importante realizar un seguimiento del progreso de una refactorización a mayor escala y saber cuándo está terminado. En comparación con estas tareas requeridas, en mi humilde opinión, el esfuerzo real de administrar un elemento JIRA es mínimo.

Se ha argumentado que el cumplimiento de PCI (un objetivo de la empresa en un futuro próximo) requiere este nivel de seguimiento

Si quiere decir esto , puedo entender por qué la gerencia teme cambios incontrolados en la base de código, sin embargo, el seguimiento de cambios es solo una pequeña parte de la solución. Necesita pruebas exhaustivas del sistema y probablemente revisiones de códigos para asegurarse de que no se filtren números de tarjetas de crédito del sistema a través de archivos de registro, etc. No se supone que la refactorización cambie el comportamiento del código existente, y se supone que tiene pruebas unitarias para probar esto. de todos modos (no intente apoyarse en la creencia de que las herramientas de refactorización automatizadas no pueden descifrar el código; DEBE realizar pruebas unitarias para evitar sorpresas desagradables).

En un mundo ideal, la respuesta de Chris es correcta. Cada vez que realice un cambio en el código o cualquier artefacto asociado con un proyecto de software, debe haber un registro de esto. Debe presentarse, aprobarse, asignarse a la parte correcta, esfuerzo estimado, trabajo realizado, tiempo total registrado y una breve descripción del cambio documentado.

Sin embargo, esto no siempre es factible. Por ejemplo, mi IDE está configurado para reformatear un archivo de código basado en las pautas de código de la organización. Si abro un archivo y veo que no coincide, es trivial solucionarlo: CTRL + MAYÚS + F en el archivo formatea todo. Tal vez un CTRL + SHIFT + O para arreglar las importaciones. Lo hago justo antes o justo después de corregir el defecto que me asignaron.

En ese caso, siempre desea registrar el hecho de que lo hizo y cuánto tiempo tardó, pero no realizar el cambio ahora podría ser peor que pasar por el proceso de asignar e implementar formalmente el cambio. En algunos casos, es más fácil pedir perdón que pedir permiso. Depende de usted, como ingeniero, justificar exactamente dónde debe trazarse esa línea.

En general, la refactorización debe realizarse como una parte normal de su flujo de trabajo. Con el fin de corrección de errores Una , es necesario prueba de que algo del método, y así debe extraer como método B . Mientras lo hace, observa que el campo C tiene un nombre muy malo, por lo que le cambia el nombre.

A mi modo de ver, estas normales refactorizaciones consiguen "cargan contra" el error original de A . Se envían con la corrección, se revisan con la corrección y se emiten con la corrección. Son parte de la solución.

Pero también hay refactorizaciones más grandes y menos enfocadas. Una observación general de que la clase D es demasiado grande. Sería más fácil trabajar en si eliminó la duplicación de E . Y esas refactorizaciones se encuentran entre las más riesgosas que tomará (particularmente en una base de código sin pruebas). Por supuesto, cree boletos para aquellos; póngalos al menos en su proceso de revisión normal.