¿Se permite el código de refactorización aleatorio en scrum?

23

Fondo

  • Mi equipo usa scrum
  • Actualmente no tengo tarea asignada
  • No hay más tareas pendientes en la cartera
  • Hoy es el Día del Trabajo para mi cliente.

Al no tener muchas cosas que hacer hoy, quería comenzar a refactorizar un código que sigo viendo en el proyecto en el que estoy trabajando, pero actualmente no estoy asignado a ninguna tarea de sprint para hacer una refactorización a gran escala.

¿Está bien en Scrum si comienzo a refactorizar al azar el código que tengo y no he escrito que siempre me molesta pero no tengo tiempo otros días para arreglarlo debido a las asignaciones de otros días?

¿Qué pasa con otros días que tengo tiempo libre entre sprints?

De hecho, creo y creo en la refactorización continua. Siempre lo hago en los fragmentos de código en los que estoy trabajando cuando se me asigna una historia, pero ¿qué pasa con algún otro código que veo que actualmente no está relacionado con lo que estoy trabajando en ese momento?

Carlos Muñoz
fuente
Creo que esto no está completamente basado en opiniones, ya que estoy preguntando específicamente sobre el proceso scrum.
Carlos Muñoz
1
Sugiero editar su pregunta para preguntar sobre los inconvenientes de refactorizar de esta manera. Eso es más objetivo, y si no hay inconvenientes, responde a su pregunta original. Quizás también mire esta pregunta para ver si las respuestas ayudan.
@ BЈовић No, escribí la pregunta el 1 de septiembre
Carlos Muñoz
1
@ BЈовић El día del trabajo es el primer lunes de septiembre en los EE. UU. El 1 de mayo es el Día Internacional de los Trabajadores. Al no estar en los Estados Unidos, me pongo a trabajar el Día del Trabajo
Carlos Muñoz

Respuestas:

29

Realmente no pretendo atacar otras respuestas, pero ¿nadie más está escribiendo pruebas automatizadas aquí? Aquí hay una lectura divertida de Martin Fowler para cualquiera que esté haciendo Scrum sin las prácticas adecuadas de ingeniería de software. Robert C. Martin también dice mucho sobre esto aquí .

Entonces, a mi respuesta ... En resumen, es así:

Sí, el código de refactorización "al azar" está permitido en Scrum , siempre que el equipo decida que debe hacerse. (Después de todo, es autoorganizado)

Y ahora por la larga respuesta:

Es evidente que dejar más y más deuda técnica después de cada Sprint es una receta para el desastre. Pronto, todos disminuirán la velocidad a medida que el código se vuelva más desordenado; cada cambio será más difícil de realizar porque el código está tan enredado y desordenado que lleva más tiempo encontrar los lugares para cambiar que realizar el cambio real. Se vuelve aún peor si tiene que hacer un cambio en un módulo grande y desordenado del que no sabe nada, se hace imposible ganar / mantener la productividad al agregar / cambiar personas en el proyecto, y así sucesivamente.

Si un equipo desea mantener estable su velocidad, debe poder mantener limpia la base del código para incrementar continuamente el software. La refactorización es una práctica obligatoria si desea mantener su velocidad durante todo el ciclo de vida del proyecto, y si desea mitigar el riesgo de agregar / cambiar personas en el proyecto, y si desea poder realizar cambios en los módulos, no sabe nada sobre, y así sucesivamente.

Sin embargo, refactorizar es una actividad muy peligrosa. Repito, es una actividad muy peligrosa . Es decir, a menos que tenga suficiente cobertura de prueba para poder cambiar de forma segura y libre la base del código. Si puede presionar un botón para verificar si nada se rompió, la refactorización se convierte en una actividad muy segura; tan seguro, de hecho, que es parte del ciclo de TDD , que es la práctica que le permite crear dicho conjunto de pruebas en primer lugar.

Pero, como los equipos en Scrum se autoorganizan, al final su equipo debe decidir qué es lo correcto. Espero haberte dado algunos argumentos en caso de que tengas que convencer a alguien. (Preste especial atención a los enlaces en el primer párrafo, y a cualquier otro artículo al que apunten)

MichelHenrich
fuente
1
¿Qué es suficiente cobertura de prueba para considerar la refactorización muy segura? Cambiar aleatoriamente el código de trabajo sin un propósito para corregir errores siempre es un riesgo.
Petter Nordlander
55
Ninguna cantidad de pruebas hace que la refactorización sea completamente segura. SQLite es una de las piezas de software más probadas, con una cobertura total de sucursales, y aún así realizan versiones de corrección de errores de emergencia todo el tiempo.
Jan Hudec
@Petter Refactoring se define como un cambio realizado en la estructura interna del software para que sea más fácil de entender y más barato de modificar sin cambiar su comportamiento observable. Un error es un comportamiento observable, por lo que no se puede "refactorizar". Utiliza refactorización en una parte del código que considera que se beneficiaría de una mejor estructura, no es aleatoria (de ahí las comillas). Sin embargo, para estar absolutamente seguro de que sus cambios no afectan el comportamiento observable del sistema, debe tener una cobertura de prueba del 100%; incluso si algo de esto se logra a través de pruebas manuales.
MichelHenrich
1
No estoy de acuerdo con que la refactorización sea NECESARIA. Sin embargo, incluso si tiene una cobertura del 100% utilizando ambas técnicas de prueba de recuadro blanco / negro, la posibilidad de no cambiar el comportamiento e introducir errores imprevistos no está cerca de cero. Una vez que se codifica una clase, casi nunca veo cambios que rompan esa clase. Ahí no es donde ocurren los errores. La mayoría de los errores ocurren cuando una clase cambia porque termina comportándose "ligeramente" de manera diferente con respecto al sistema, a pesar de que todavía "técnicamente" hace exactamente lo mismo. Por ejemplo, acaba de hacer que la clase sea segura para subprocesos, ooops ahora funciona porque su llamada está bloqueada
Dunk
2
La cobertura del 100% del código no evita absolutamente la introducción de errores. Aunque cada línea de código se prueba, no todos los estados posibles del programa se probarán.
bdsl
11

Scrum realmente no dice nada sobre refactorización.

Lo que Scrum dice es que si no tienes ninguna tarea dentro del sprint para trabajar, debes apoyar al resto de tu equipo para alcanzar la meta del sprint. Incluso si eso significa buscar café para ellos.
Si su equipo está de acuerdo en que refactorizar el código es la mejor manera de apoyarlos (y eso incluye contar con la infraestructura para garantizar que la refactorización no introduzca demasiados errores nuevos), entonces hágalo.

Bart van Ingen Schenau
fuente
4

Yo diría que no, no lo es. Esto es independientemente del tipo de trabajo (refactorización, etc.).

Como mínimo, las tareas deben crearse e insertarse en su sprint actual. El propósito del seguimiento del tiempo es capturar su velocidad para poder trazar efectivamente sprints futuros. Si está trabajando en cosas sin rastrearlas, tendrá un impacto en la velocidad y no mejorará con el tiempo como se pretende con un seguimiento adecuado (es probable que regularmente no tenga suficiente trabajo porque su velocidad proyectada es menor que su velocidad real )

En cuanto a la refactorización del trabajo en sí mismo, puedo hablar de eso, pero no lo haré, ya que no creo que sea la pregunta central que estás tratando de responder.

Demian Brecht
fuente
1

Voy a decir que no también. Re-factorizar a menudo conduce a errores no intencionados si no se maneja de la manera correcta.

Como gerente general, periódicamente pondría a todos en otro proyecto y pasaría una semana haciendo revisiones de código / refactorización / cambio de nombre y aplicación de convenciones en un proyecto. Estos sprints de refactorización casi siempre serían de naturaleza cosmética. Cualquier refactorización funcional se planificaría con anticipación e involucraría al desarrollador original.

La refactorización funcional siempre debe planificarse y coordinarse como parte del proceso scrum para que se pueda realizar un seguimiento del tiempo y todos los miembros del equipo necesarios estén disponibles para validar el proceso. Un desarrollador no debería cambiar el código escrito por otro fuera de pista porque lo más probable es que solo arruine el sprint actual para todos. Especialmente cuando se trata del tiempo de fusión de código.

Si se trata de un proyecto del cual usted es el único responsable y es su propio tiempo libre, puede ser diferente suponiendo que tome medidas para asegurarse de no causar retrasos innecesarios en su sprint actual.

En caso de duda, consulte a su gerente.

EDITAR: También quiero mencionar que un determinado código que no le gusta puede tener un determinado objetivo de rendimiento asociado. Puede que no te guste, pero puede ser más rápido que cualquier cosa que puedas construir que se adapte a cómo quieres usarlo. Solo otra razón por la cual la refactorización funcional siempre debe ser un proceso administrado.

muchas patatas fritas
fuente
1
¿Qué quieres decir con "refactorización cosmética"?
Bћовић
Función, clase y nombres constantes. Mover propiedades a la parte superior del archivo y funciones relacionadas juntas. A veces, mover funciones de instancia a estática. Principalmente para asegurar que se aplique un estilo común de nomenclatura y estructura. Esto crea una especie de coherencia en la base del código que nunca sucedería naturalmente.
montón de patatas fritas
1

Scrum no dice nada sobre la refactorización (ver una conferencia de Robert C. Martin, "La tierra que se olvidó de scrum").

En Scrum, las tareas están dirigidas a las funciones de su software especificadas por el cliente, no a las deudas técnicas para pagar mediante refactorización. Estos son niveles de abstracción totalmente diferentes. El cliente en su mayoría no puede evaluar la necesidad.

Scrum es gestión estadística de proyectos. Para obtener medidas significativas de "cuánto tiempo lleva", debe conocer el rendimiento (salida por sprint). Se compara la estimación y la duración real de una característica durante al menos más de 1 sprint para entrar en la estadística. Recomiendo 5 sprints. Pero eso depende de tu equipo.

Lo principal es mantener las medidas significativas y comparables para hacer posible cualquier pronóstico. Ese no será el caso si el rendimiento está disminuyendo debido a deudas técnicas.

Si todavía piensa en refactorizar tareas, tiene dos problemas: 1. Un cliente, que no comprende, por qué tiene que aceptar una tarea que no producirá una nueva característica 2. Distorsiona totalmente sus estadísticas y, por lo tanto, su capacidad para pronosticar a medida que cambia repentinamente una variable diferente que no se consideró en sprints anteriores

En ambos casos, compromete la idea de scrum ya que desea hablar sobre las características con el cliente Y hacer pronósticos confiables para "¿Cuánto tiempo lleva?" de manera estadística. Para estar seguro, debe mantener su base de código en una calidad constante (tal vez alta).

La refactorización es la mayoría de las veces una tarea subterránea. Las refactorizaciones "geniales" significan que las refactorizaciones "pequeñas" no se han procesado en el pasado.

Una última nota: si realiza refactorizaciones, asegúrese de tener el componente bajo prueba que está refactorizando. Ohh, no tienes pruebas? Haz una tarea para escribir pruebas. Su cliente estará feliz de saber que el software que está utilizando actualmente no tiene suficiente cobertura de prueba ...

Mantenga las cosas técnicas lejos del cliente y haga su trabajo como desarrollador profesional.

oopexpert
fuente
0

Aquí hay un enfoque: ¡haz las dos cosas!

La refactorización a menudo es propensa a errores o consume más tiempo de lo que originalmente se estimó como señala @misterbiscuit.

Por lo tanto, considere un intento de hacerlo un borrador o un pico. No necesita buscar aprobación o anunciarse si en esta etapa.

Luego, busque incluirlo a través de uno de los dos canales:

  • un boleto existente que toca el mismo código / funcionalidad donde puede envolverlo razonablemente. Razonablemente según lo acordado con otros miembros del equipo.
  • un boleto completo para su revisión en la próxima preparación del boleto (o reunión semanal, etc. si es una cascada). En ese momento puedes justificarlo.

Una vez que obtenga la aceptación real, puede buscar aplicar o rehacer su pico y hacer que el código real se fusione con la rama de la línea principal (maestra, etc.).

Esto tendrá varias ventajas:

  • Todos sus códigos de código a través del mismo proceso, se prueban, QA, en la tubería de lanzamiento, etc.
  • Obtiene una aceptación formal, incluso por parte del gerente de producto, de que la refactorización es parte del oficio y no es algo que deba ser 'infiltrado' en vacaciones. Pregúntese por qué no se está "infiltrando" en una característica real que puede ayudar a la perspectiva.
  • Puede solicitar emparejamiento, revisión de código, qa, devops y todo el soporte que pueda necesitar para el cambio de código de factoring. Todo será oficial, de acuerdo con la Política y el Procedimiento y por encima del tablero.
  • Si es una empresa que cotiza en bolsa y cumple con SOX, es probable que desee / necesite hacer este tipo de proceso formal (es decir, documentarlo y luego seguirlo).
  • Obtiene una mejor reputación tanto con el gerente de producto (el cambio se realizó rápidamente) como con el equipo de desarrollo (se mejoró la base de código).
  • La organización busca preocuparse por la calidad del código, lo cual es bueno para la productividad, la moral, la retención de los empleados y muchas otras razones.
  • El efecto sobre la velocidad del proyecto puede rastrearse más fácilmente cuando se incluye todo el trabajo. Puede estar bien no designar ningún punto, ya que la presencia misma puede usarse para afectar la velocidad.
  • Es probable que los desarrolladores vean herramientas que fomenten revisiones de código más fáciles como Fisheye, Github, etc.
  • Es más probable que los desarrolladores vean algunos estándares básicos (a veces documentados, a veces no) que hacen que el código compartido y, por lo tanto, la refactorización sea más fácil. A veces, una gran parte de la refactorización es elegir un estilo y luego aplicarlo ampliamente (reemplazando una mezcla de enfoques por uno).

Un comentario final: evite que el gerente de producto escuche la palabra 'aleatorio'. Pueden responder de manera más favorable con la actualización de código 'dirigida, estratégica, que mejora el rendimiento'. O paquete de servicio de aplicaciones. O cualquier idioma que te brinde cobertura.

Michael Durrant
fuente
0

La refactorización aleatoria no tiene sentido. Lo que tiene sentido es la refactorización de un código que introducirá la mayoría de los beneficios. Eso significa :

  • arreglar un problema de diseño o arquitectura
  • mejorando la implementación

¿Está bien en Scrum si comienzo a refactorizar al azar el código que tengo y no he escrito que siempre me molesta pero no tengo tiempo otros días para arreglarlo debido a las asignaciones de otros días?

De esta respuesta :

Mantener el código mantenible debe ser un elemento en su lista de grabación (si usa un Scrum). Es tan importante como el nuevo desarrollo. Si bien puede no parecer algo que sea "visible para el usuario", ignorarlo aumenta su deuda técnica. En el futuro, cuando la deuda técnica se acumule lo suficiente como para que la falta de mantenimiento de su código ralentice el desarrollo, los retrasos en el desarrollo de nuevas características serán visibles para los clientes.

En mi trabajo anterior, teníamos algún tipo de scrum, con sprints más grandes (2-3 meses). Como tuvimos algunos retrasos entre sprints (1 mes), utilizamos este tiempo para analizar el software y refactorizar el código.

BЈовић
fuente