¿Cómo manejo la refactorización que lleva más de un sprint?

Trabajo con una base de código que tiene más de 500 mil líneas de código. Tiene una gran necesidad de refactorización. Se han identificado esfuerzos de refactorización que tomarán más tiempo que el sprint normal de dos semanas. Estos no se pueden dividir en tareas más pequeñas como he visto sugeridas en otras respuestas en este sitio. El producto debe funcionar al final de la iteración, y la refactorización parcial dejará el sistema en un estado inutilizable ya que la dependencia entre los elementos es horrible. Entonces, ¿cuál sería la mejor manera de abordar este obstáculo? Una vez más, menciono, dividirlo en pedazos más pequeños no es una opción, eso ya se ha hecho.

Actualización: Las personas parecen necesitar una explicación de por qué esto no puede encajar en un sprint de 2 semanas. Hay más cosas involucradas en un sprint que solo escribir código. Tenemos una política de no código sin pruebas. Esa política no siempre existió y una gran parte de la base de código no los tiene. Además, algunas de nuestras pruebas de integración siguen siendo pruebas manuales. El problema no es que la refactorización en sí sea tan grande. Es con el hecho de que pequeños cambios tienen un efecto en muchas partes del sistema, y ​​debemos asegurarnos de que esas partes sigan funcionando correctamente.

No podemos posponer o extender un sprint porque tenemos revisiones mensuales. Entonces, este cambio que se extiende más allá de un sprint no puede detener el otro trabajo que se agrega al hotfix.

Refactorización vs rediseño: el hecho de que nuestro proceso de desarrollo no sea lo suficientemente eficiente como para manejar esta refactorización en un ciclo de dos semanas no garantiza cambiarle el nombre a un rediseño. Me gustaría creer que en el futuro podríamos realizar exactamente la misma tarea dentro de un ciclo de dos semanas a medida que nuestro proceso mejore. El código en cuestión aquí no ha tenido que cambiar en mucho tiempo, y es bastante estable. Ahora, a medida que la dirección de la empresa se está adaptando más al cambio, queremos que esta parte de la base del código sea tan adaptable como el resto. Lo cual requiere refactorizarlo. Con base en las respuestas aquí, se está haciendo evidente que faltan los andamios necesarios para que esta refactorización funcione en el marco de tiempo de los sprints normales.

Responder:

Voy a hacer el enfoque de ramificación y fusión que Corbin March sugirió la primera vez para que podamos aprender más sobre estas áreas problemáticas y cómo identificar las pruebas faltantes. Creo que, en el futuro, deberíamos adoptar el enfoque que Buhb sugirió para identificar las áreas a las que les faltan pruebas e implementarlas primero, luego hacer la refactorización. Nos permitirá mantener nuestro ciclo de sprint normal de dos semanas, como muchos aquí han estado diciendo que siempre debería ser el caso para la refactorización.

Si tiene el lujo de retrasar la refactorización, le sugiero que centre las próximas iteraciones en agregar pruebas unitarias y pruebas de integración automatizadas hasta el punto en que pueda refactorizar cómodamente la base de código y luego refactorizar en un solo sprint.

Mi sugerencia:

1. Crear una rama
2. Fusionar diariamente desde el tronco a su rama y resolver conflictos.
3. Trabaja hasta que esté hecho. Su rama puede estar fuera del desarrollo central para varios sprints.
4. Combinar de nuevo al maletero.

No hay forma de evitar el hecho de que probablemente se pondrá feo. No te envidio. En mi experiencia, cuando cambias drásticamente un proyecto, es más fácil fusionar el desarrollo continuo en el nuevo paradigma que fusionar de alguna manera el nuevo paradigma en un tronco ahora cambiado después de que todo haya terminado. Aún así, va a doler.

No todas las tareas se pueden hacer en un sprint (artificial) de 2 semanas, por lo que se requiere sentido común. Si ya no puede desglosarse, y debe hacerse, simplemente súbase y hágalo. El proceso no es más importante que el resultado final, y debe verse como una guía más que como una ley que nunca se debe violar.

Simplemente haz un sprint de 3, 4 o 5 semanas. ¿A quien le importa? Obviamente estás convencido de que no se puede hacer nada en un período de tiempo más corto, así que deja de luchar contra él.

Simplemente no se lo digas a tus compañeros en The Royal Society of Blind Agile Adherance.

Recomiendo comenzar con el libro Working Effectively with Legacy Code , de Michael Feathers. Cubre una variedad de técnicas para reducir el alcance de los cambios de estilo de refactorización.

En nuestra tienda, cuando tenemos grandes tareas de refactorización o reescritura que no se pueden completar en una ventana de lanzamiento, dejamos la funcionalidad tal como está en el sistema. Pero comenzamos con las nuevas funciones refactorizadas de bloque de lego según lo permita el tiempo. Eventualmente, llegamos a un estado en el que tenemos suficientes bloques de lego, que un sprint proporciona suficiente tiempo para conectar los bloques de lego en la aplicación y activarlo para los usuarios.

De manera más concisa, separamos o reelaboramos grandes funciones con nuevos nombres. Luego, al final, usamos nuestro trabajo renombrado y refactorizado en lugar del viejo código desagradable.

Dedique un sprint a descubrir cómo mantener el código funcionando correctamente a mitad de refactorización. Esto puede tomar la forma de métodos y clases en desuso, envoltorios, adaptadores y similares. Su refactorización puede ensuciar el código por un corto tiempo para que sea más limpio a largo plazo; está bien. En este momento estás diciendo que no se puede hacer. No creo que sea correcto: piense en cómo sería su proceso si se pudiera hacer, piense en los pasos que puede seguir para hacerlo. Entonces sumérgete.

+1 en la respuesta de Corbin March, eso es exactamente lo que estaba pensando. Parece que su código base es un poco feo y tomará más de un ciclo de sprint para limpiarlo.
Entonces, como dijo Corbin,

1. bifurcarlo en un "proyecto de refactorización"
2. prueba tu cambio de sucursal
3. promover a su entorno de prueba para pruebas de control de calidad
4. Vuelva a fusionarlo gradualmente en el tronco hasta que finalice la refactorización.

Estoy seguro de que no tendría ningún problema en venderle esto a su gerente de desarrollo, si sus PM tienen dificultades para verlo, explíqueles que Roma no se construyó en un día y que limpia toda la basura arrojada a Roma. las calles tampoco se van a hacer en un día. La refactorización llevará un tiempo, pero al final valdrá la pena en términos de mantenimiento más fácil, lanzamientos de mejoras más rápidos, menos tickets de producción y un SLA más completo.

Aunque el rediseño que realmente desea hacer es una tarea grande, ¿sería posible refactorizar piezas más pequeñas para romper / desacoplar dependencias individuales? Ya sabes, cuando tengas dudas, agrega indirección. Cada uno de estos desacoplamientos debe ser una tarea más pequeña que la gigantesca que no puedes completar.

Una vez que se eliminan las dependencias, debe poder dividir las tareas de refactorización restantes para que se puedan obtener dentro de los sprints.

En el proyecto para el que estoy trabajando en este momento, estamos usando sprints de 4 semanas. Y a veces no podemos terminar una historia de usuario y simplemente la reiniciamos durante el siguiente sprint.

Sin embargo, en mi humilde opinión, debería ser posible dividir una refactorización en historias más pequeñas que caben en un sprint de 4 semanas. Si no puede llevar el código a un estado coherente en 4 semanas, tengo la sensación de que está reescribiendo su aplicación en lugar de refactorizarla.

Recomiendo que cuando ciertas tareas demoren más que el ciclo de sprint de 2 semanas, la tarea se programe para otro momento. Su equipo ha identificado la necesidad de refactorizar y eso es importante. A veces, no hay otra opción ... y, sí, eso apesta.

Cuando llegue el momento de comenzar la refactorización, simplemente suspenderás los sprints normales. No tienes elección. Utilice el control inteligente de versiones: bifurcación, refactorización, prueba, fusión. Siempre hay un momento en el que la refactorización de algunos proyectos grandes tiene prioridad sobre las características. Si es posible, también trataría de separar las preocupaciones para una mejor flexibilidad.

Habiendo pasado recientemente por el mismo problema con una parte de nuestra base de código (que también es un poco más grande), espero poder compartir algunas ideas con usted. En mi situación, la base de código había sido desarrollada por otro equipo, por lo que nadie de los desarrolladores originales estuvo involucrado en esta refactorización. Mi experiencia con la base de código fue de aproximadamente 1 año, y otro desarrollador le encargó 2 años.

Permítanme dos pequeñas notas con respecto a las otras respuestas aquí:

• La ramificación lo ayudará a establecer un patio de recreo para usted, pero nunca combine sus cambios en el tronco en un gran conjunto de cambios. Tendrás serios problemas con el resto del equipo.
• Debe hacerlo de forma incremental, y se puede hacer. No hay excusas. Lea Trabajo eficiente con código heredado de principio a fin. Leelo de nuevo.
• Pensar que puedes hacerlo es un gran paso es una falacia. Aunque parece más trabajo, hacerlo de manera incremental es mucho más fácil de administrar.

Pasar aparentemente "fuera de reserva" durante dos semanas o más no pasará desapercibido. Debe asegurarse de contar con el respaldo de la gestión de proyectos y, lo que es más importante, del equipo. Si el equipo no está comprometido con esta refactorización (y esto significa, hazlo ahora, no en un futuro lejano), te meterás en problemas.

No lo hagas solo, usa la programación de pares. Esto no significa estrictamente que deba sentarse frente al mismo teclado todo el tiempo, sino que puede manejar tareas pequeñas y estrechas (por ejemplo, escribir pruebas que capturen el comportamiento de esta clase) individualmente.

Haga una refactorización de rasguños y trátelo como tal. (¡Una especie de refactorización prototipo "desechable", el bit "desechable" es importante!) Honestamente, es poco probable que sepas todas las implicaciones que tendrá tu refactorización. Una refactorización scratch lo ayudará en ciertos aspectos:

• Descubrirá piezas del sistema que nunca supo que existían.
• Tendrá una mejor visión de cómo se interconectan los módulos
• Descubrirá una nueva forma de agrupar su sistema en módulos, probablemente muy diferente de su comprensión actual. Discuta ideas con su pareja. Intenta destilar tu nueva vista. Escriba un documento técnico breve sobre arquitectura (o dibuje un diagrama) que diga dónde están las cosas actualmente y dónde deberían pertenecer lógicamente.

Cuando hayas refactorizado desde cero, espero que descubras que no puedes simplemente ir y cambiar todo. Te sentirás mal, es solo un gran desastre y no puedes simplemente accionar un interruptor y hacerlo funcionar. Esto es lo que me pasó, puede ser diferente en tu situación.

Sin embargo, mi compañero y yo entendimos mucho mejor nuestro sistema. Ahora pudimos identificar refactorizaciones / rediseños individuales, más pequeños (aunque todavía grandes). Capturamos nuestra visión del sistema en un diagrama y lo compartimos con el equipo, junto con los elementos del trabajo atrasado que se nos ocurrió para implementar esa visión. Con el poder de un consenso común, decidimos qué elementos implementaríamos en el transcurso de la próxima iteración.

Una última cosa que nos ayudó fue usar una gran pizarra. Hay demasiadas cosas para tener en tu cabeza. Es muy importante que guardes notas. Escríbete una nota de resumen al final del día, capturando lo que has hecho hoy y quieres hacer mañana. Ayuda a relajarse a lo grande, y necesita un momento relajado si desea mantenerse al día con la tarea. ¡Buena suerte!

Inicie una ventana de mantenimiento durante la cual no se realiza ningún desarrollo adicional. Realice el rediseño, luego reanude los sprints de desarrollo.

Tenemos dos tipos de trabajos a nuestra mano:

1. Trabajos de hora hombre
2. Obras de genio

La refactorización generalmente consiste en el primer tipo de trabajo, ya que muchos desarrolladores ya conocen muchos métodos como DRY , SRP , OCP , DI , etc. Por lo tanto, cuando un proyecto tarda dos meses en refactorizarse, simplemente lleva dos meses , hay No hay forma de evitarlo. Por lo tanto, mi sugerencia sería no refactorizar el proyecto original y dejar que funcione en su situación actual. Deje de recibir nuevas solicitudes y requisitos de las partes interesadas y el propietario del producto . Luego, deje que el equipo trabaje en el proyecto hasta que se refactorice y esté listo para comenzar.

Una sugerencia que puede ser útil: si tiene un código no probado que no tiene tiempo suficiente para refactorizarlo y volver a probarlo dentro del sprint de dos semanas, considere primero realizar otros pequeños cambios no relacionados al código para que pueda concentrarse en pruebas de escritura para el primer sprint o dos. Quizás pueda identificar varios clientes no probados del código que desea refactorizar; elija un cliente y realice otros cambios de alguna utilidad para el negocio que lo obligarán a escribir pruebas para ese cliente. Una vez que esté más familiarizado con el código, después de trabajar con él, y tenga más pruebas, y posiblemente haya realizado algunas refactorizaciones menores, estará en una posición mucho mejor para lograr la refactorización y la (ahora más fácil ) probar ambos en una iteración.

Otro enfoque es hacer una copia del código ofensivo, refactorizarlo y luego mover a los clientes uno por uno al nuevo código. Este trabajo se puede dividir en iteraciones.

Y no te rindas: no aceptes que una refactorización grande no se puede dividir en pasos más pequeños. El enfoque más fácil / rápido / mejor puede llevar más tiempo que una iteración. Pero eso no significa que no haya forma de hacer fragmentos del tamaño de iteración.