Cómo sobreviví a un PR de 11,000 líneas - y lo llevé a producción en 2 días.

Parte 1: Pensar en la solución.

Cuando empecé a desarrollar esa feature que se veía muy grande, dividí la feature en partes. Entonces, mi primer pensamiento fue: “Hagamos todo el manejo de datos y creo use cases en el primer PR y hago unit testing”.

Como esto era una feature nueva, todo código nuevo no iba a dañar nada. Al final el primer PR fue un éxito; fueron los “foundations” para poder construir la UI, no sabía si la UI me tocaría a mí.

El primer PR: Puede parecer gigante, pero quitando el código generado eran de la mitad.

Yo me sentí feliz; parecía que lo siguiente, la UI, no me iba a tomar tanto código, era soportar “3 features principales” y algunas secundarias. Este pensamiento fue un error, cuando miraba las features se dividen en:

• Crear.
• Visualizar.
• Mover.

Empecé por la de crear y cuando la terminé pasaron dos cosas: una, no tenía nada que visualizar, entonces el crear no se podía probar, así que arranqué a crear el visualizar; hasta acá todo era “color de rosas”. (no la había completado)

En el equipo tenemos la costumbre de enviar demos para mostrar el progreso y en ese momento recibí mi primer feedback temprano.

Mi yo del pasado debió mezclar en este punto.

Parte 2: La espiral de código infinito.

El feedback fue que la definición en Figma y en el ticket estaba mal hecha en el crear; el crear no era como yo lo había hecho. Para poder hacer lo que se requería, necesitaba terminar el visualizar para poder usarlo en el crear.

En este punto tenía unas 2000 líneas de código y erradamente pensé que no tenía nada. El visualizar estaba incompleto y el crear estaba mal hecho.

Ahí no fui capaz de mirar fuera de la caja y volver a dividir el problema; me quedé con la división inicial, pero como ahora el crear y mover dependían del visualizar, el problema había cambiado, mi división era incorrecta.

Manitos a trabajar y terminé el visualizar de 2000 líneas con más cosas que me tocó soportar, algunas definiciones que tocó cambiar con backend (cambios en los foundations). Este PR ya estaba cerca de las 5000 líneas de código.

Momento en que QA probará parcialmente los cambios, pero nuevamente me pasó que podía ver, pero el crear no funcionaba bien, entonces lo que QA pudo probar fue muy poco.

Parte 3: Terminamos.

Con el visualizador listo, yo tenía en mente dos cosas:

• Crear una base de código para los 3 problemas.
• La acción de moverla la iba a dejar para después.

Importante: a medida que hacía cambios, subía los cambios, creaba una nueva build y el equipo QA me daba feedback. Mientras avanzaba, iba dejando la app “sin bugs”.

Tuve reunión de planeación y pregunté si podía dejar el mover para después. Yo sabía que tenía retos, pero parte de la lógica del mover ya estaba porque era usar el visualizador para seleccionar la nueva ubicación y ejecutar un llamado al backend. Respuesta: No. Entonces que alguien me ayude porque no voy a terminar el PR. Era un monstruo y, a diferencia del primer PR de foundations, que tenía unit testing y mucho código generado, este tenía todo código.

Al final recibí ayuda, pude solucionar los problemas que día a día me reportaba el equipo de QA, refine lo que más pude del código y estaba listo, listo para que todo se integrara a dev.

Todo fue un éxito. La feature, después de pasar a la rama develop, se solucionaron algunos bugs menores y se cambiaron algunas definiciones, pero el éxito de la feature, a pesar de que era un código que involucraba 5K líneas de foundation + 11K líneas de UI, se llevó a producción 2 días después de mezclar.

El éxito se debe en parte al equipo y colaborar con ellos para que se pudiera ver el avance poco a poco.

📖 TL;DR

• Dividir tareas grandes en partes más pequeñas facilita la revisión de código y la detección de errores.
• Un PR extenso dificulta las revisiones exhaustivas, aumentando el riesgo de errores.
• Pruebas unitarias, integración continua y pair programming mejoran la calidad del código.
• Desplegar y probar el código por etapas aumenta la confianza en su correcto funcionamiento. (Crear demos y recibir feedback)
• Segmentar el trabajo permite entregas incrementales y retroalimentación continua.
• La familiarización con el código a través del pair programming facilita su revisión.
• Seguir patrones y guías de estilo reduce la complejidad de las revisiones de código.
• Evaluar cuando el problema cambia y la solución debe cambiar.
• No todo depende de ti, hay factores externos en este caso: Malas definiciones, cambios en la UI, se agrandó el scope.
• Si son features nuevas, tienen menos riesgo de romper cosas. (no te fíes)

Conclusión

La comunicación con el equipo para encontrar una estrategia más adecuada en cada paso es muy importante.Es imposible que todos tus PRs sean pequeños. A medida que tu proyecto es más grande, las features son más complejas, así que la experiencia en este proyecto me lleva a entender que no siempre podemos dividir las cosas; no siempre serán PRs pequeños. Algo que no hice es parar y mirar fuera de la caja para replantear si debo abordar el problema de forma diferente.

1️⃣ Cambios incrementales: en lugar de esperar hasta el final para hacer un gran PR, haz cambios incrementales. Los PR más pequeños y enfocados son mucho más fáciles de revisar, probar y depurar.

2️⃣ Claro y conciso: Asegúrate de que tus PR sean claros y concisos. Incluye una descripción detallada que describa qué cambios se han realizado y por qué.

3️⃣ Estrategia de ramificación: adopta una buena estrategia de ramificación. La ramificación de funciones o tareas puede ayudar a mantener los PR manejables y enfocados en un solo aspecto del proyecto.

4️⃣ Complejidad: Entre más grande sea tu proyecto, más complejas serán las features; el unit testing te ayudará a tener más confianza.

Recuerde que el objetivo de una PR no es solo agregar código, sino también mantener la calidad y garantizar que todos los miembros del equipo puedan realizar futuras actualizaciones.

👋 Saludos y nos vemos en una próxima entrega.

Gracias por leer hasta aquí. Considera darle un me gusta, compartirlo y estar atento a futuros artículos. No dudes en contactarme a través de LinkedIn.