¿Cómo determinar la prioridad y la gravedad de una "mejora del código"?

Tenemos campos de "prioridad" y "gravedad" en nuestro sistema de seguimiento de errores. Definimos la gravedad como "cómo impacta al usuario" y la prioridad como "cómo impacta al producto".

Mi pregunta es sobre cómo clasificar una tarea de "mejora de código" en severidad y prioridad. Suponga que la mejora no cambia ningún comportamiento, sino que lo convierte en un "mejor código". Anticipamos una mejora de mantenimiento a largo plazo en general, pero es difícil de cuantificar.

Cuando usamos nuestras definiciones de prioridad y gravedad, una mejora del código obtiene los valores más bajos para ambos, a menos que introduzca algunos beneficios difíciles de predecir a largo plazo en la imagen. Por lo tanto, implica que la mejora del código es una tarea civil y nunca debe intentarse.

Sin embargo, creo que es crucial mejorar y refactorizar constantemente el código, porque:

• El desarrollo de software es en sí mismo un proceso de aprendizaje continuo y sin mejorar el código no se puede mejorar.
• Un equipo debe estar orgulloso de su código.
• El mantenimiento futuro tomará menos tiempo y, a largo plazo, los ahorros serán significativos.

¿O cree que tales tareas nunca deberían crearse y que tales mejoras deberían realizarse solo "a pedido", "cuando se asocian con un error"? Incluso si está asociado con un error, ¿no sería un punto de discusión en una revisión de código, por ejemplo, "por qué hiciste este cambio drástico en la estructura?".

Por lo general, no me gusta ver las actividades de "mejora de código" como una tarea asignable separada porque la mejora de código en sí misma nunca lo acerca más a completar historias o requisitos de usuarios. Es por eso que las tareas de mejora de código siempre tendrán una prioridad tan baja que nunca se asignarán.

Veo la mejora del código como una constante, algo que todo desarrollador debería hacer tan naturalmente como escribir en un teclado. Lo considero en mis estimaciones para cualquier tarea. Si mi tarea me obliga a tocar una clase o algún código fuente que no se ha examinado en mucho tiempo, entonces asumiré que probablemente es necesario algún trabajo de limpieza y aumentaré mi estimación en consecuencia.

En el mejor de los casos, termino la tarea temprano y puedo usar el tiempo restante para mejorar el código o incluso el diseño. En el peor de los casos, la tarea lleva mucho más tiempo de lo esperado, pero tengo ese tiempo extra como búfer.

Si desea refactorizar su código, establezca la prioridad de la tarea de acuerdo con su definición (es decir, "cómo afecta al producto"). Algunas refactorizaciones no afectarán mucho al producto y otras sí, dependiendo del alcance del trabajo requerido. Establecer una prioridad más alta indicará que será necesario realizar más pruebas después de que se complete la refactorización para garantizar que no haya ocurrido nada inesperado.

También es posible que desee introducir una nueva categoría en su sistema de seguimiento de errores para clasificar este tipo de tareas como tareas de "Refactorización". De esta manera sabrá cómo interpretar el valor de prioridad; es decir, mayor prioridad significa mayor impacto y, por lo tanto, se requieren más pruebas.

Lo que falta es verificar sus suposiciones sobre el código existente: se puede lograr menos tiempo y ahorros significativos si mejoramos el código. ¿Es esto cosmético o hay problemas serios?

Verifique sus estimaciones de depuración y mejora. Si están tardando más y hay comentarios continuos sobre tener que refactorizar el código primero o limpiarlo, esa puede ser su mejor medida. Luego, puede identificar su base de código como: Bueno, necesita modificaciones menores o se requiere una refactorización seria.

Todo esto es relativo. Es difícil dar esta alta prioridad cuando hay clientes que desean más funciones y están dispuestos a pagar de inmediato por las horas facturables.

Interesante pregunta.

Creo que tendría que estimar cuántas líneas de código y cuántos módulos podría afectar un cambio.

Tal vez podría ver cuántas pruebas unitarias, si las tiene, se romperán al hacer el cambio. Esto probablemente significaría intentar el cambio en una rama primero para tener una idea.

Luego tenga umbrales para estos niveles coincidentes de prioridad y gravedad.

También debe tener en cuenta que tendrá que participar mucha prueba de prueba. Si el cambio toca una gran superficie de la aplicación, puede que sea necesario revisar muchas pruebas del sistema.

Comencemos con dos supuestos aquí.

1. Para cada nueva historia, escribes tu código lo mejor que puedas, posiblemente respaldado con el conocimiento ambiental de tu equipo.
2. Cada vez que tiene una historia que cambia la funcionalidad del código existente, utiliza su nuevo conocimiento del sistema y mejores habilidades para mejorar el código en el proceso de implementación de la nueva historia.

Dados estos dos supuestos, nunca es necesario un esfuerzo explícito de "mejora del código". Su código mejora a medida que escribe el sistema. Esto significa que no todo el código está a la altura de sus últimos y mejores estándares de mantenibilidad, pero "si no está roto, no lo arregle". Considero refactorizar el código que no necesita ser cambiado para ser "dorado" tanto como agregar funcionalidad visible innecesaria. Si el código se rompe de alguna manera, escriba una prueba válida que falle; registrar un error; y luego refactorizar para abordar ese error.

Me robaría la votación del movimiento ágil:

Ingrese el error, haga suposiciones aproximadas de gravedad y prioridad,

Luego, revise diariamente, semanalmente o mensualmente todos los errores nuevos y vote sobre sus calificaciones. Lo ideal es hacer esto durante una reunión de planificación de sprint con usuarios finales. Luego puede hablar sobre las siguientes características en ese momento también y ser positivo,