Acéptalo, Tu Primera Idea Fallará
La primera vez que escuché que los primogénit@s no somos lo mejor que nuestros padres hicieron, me dije a mi mismo: “Pfff, ¡patrañas!”. Luego, descubrí algo llamado Refactorización y entendí que tal vez mis hermanas menores sí están en lo correcto 😕
Primogénit@s, ¡no se sientan mal! Sigan leyendo para saber cómo nos reivindicamos a través de la tecnología. Siempre hay #revancha 😉
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Al poner en marcha una arquitectura de software, entregar una aplicación o incluso un nuevo feature de ésta, sentimos ese orgullo que todo artista del código (alias: programador) siente en el pecho. Pensamos que el haber utilizado ReactJS 16.5, Machine Learning de AWS o cualquiera que sea la tecnología de moda nos transforma en Rockstars 🎸, pero un par de semanas más tarde, caemos en cuenta de que se encontraron errores en el feature, que la arquitectura no funcionaba tan bien como la habíamos diseñado o que ya existe ReactJS 32.9 y que aquello que creamos ahora es considerado obsoleto.
Retomando el pensamiento inicial de este post, ahora entendemos que nuestras ideas primogénitas no serán las más acertadas puesto que solo podemos ver su impacto una vez que estas son probadas en el campo de batalla; en Producción con los usuarios.
Si el resultado no es tal y como se esperaba, bueno, humildemente lo reconocemos y así tenemos la oportunidad de refactorizar la funcionalidad. Por el contrario, si el resultado fue el deseado, pues ¡que bueno! (palmada en el hombro para tí y a esperar porque sé que volverás a este post en un par de meses/años :P ).
Recuerda esto: escribir código y no realizar la refactorización necesaria es como subir: una foto a Instagram sin filtros, publicar un blogpost sin editarlo, improvisar una canción y lanzarla en Spotify sin realizar los ajustes melódicos necesarios, o tener un hijo y no educarlo. ¡Sí!, existe la probabilidad de éxito (conocido como el “Principio de Favorabilidad” o “Suerte de Principiante”), pero tarde o temprano esta termina y en el caso de la tecnología, la suerte tiene una vida muy corta.
Tranquil@, no sugiero re-hacer una y otra vez las implementaciones previas en lugar de crear nuevas. Sugiero ejercitar el músculo de la introspección para así identificar qué es aquello que debe ser mejorado en el presente para facilitar la evolución de tu producto en el futuro.
Estrategias de Refactoring
Para evitar incurrir en una deuda técnica colosal, toma en cuenta estas estrategias para lograr una cadencia regular de refactoring:
1. Regla del 20%
Marty Cagan: (“Headroom” Technique) Destina al menos 20% (o más) de la capacidad de tu equipo para reescribir, refactorizar, re-diseñar arquitecturas de software. Esto te ayudará a prevenir que tengas que hacerlo en un punto en el cual la refactorización costaría mucho tiempo, dinero y usuarios.
El consejo de M. Cagan en Inspired es claro: alocar por lo menos 20% de la capacidad de tu equipo de desarrollo por Sprint para refactorización. Sí, sé que pensarás: “20% reservado para refactoring es 20% menos de productividad”. Así que te pregunto: “¿Cuántas ideas innovadoras tienes que no pueden ser implementadas por miedo a romper funcionalidad?”
2. Kaizen-Blitz
Vale, como tal vez no estés de acuerdo con la Regla del 20%, acá va otra alternativa. En lugar de destinar un porcentaje del Sprint para refactorización, planifica que cada 3 o 6 Sprints, uno de estos sea exclusivo para refactoring (…lo sé, no puedes salvarte de la refactorización :P). Eso es lo que Kaizen-Blitz simboliza en esencia; un alto en la producción para únicamente enfocarse en las mejoras que el equipo identificó que deben ser realizadas.
ALERTA: no confundas Bug Fixing de los errores encontrados en la aplicación con Kaizen-Blitz. El primero es parte del día a día del desarrollo (si no lo es en tu equipo, entonces necesitas revisar lo que es Continuous Testing) y lo segundo es refactorización para facilitar la evolución.
3. Red, Green, Refactor (TDD)
Test Driven Development (TDD), también conocido como “Red, Green, Refactor” ayudará a crear el hábito de introspección, y a la vez a validar la robustez de tu aplicación a través de Unit Tests (¡Dos pájaros en un tiro!). Observa cómo funciona TDD:
Tres simple pasos para TDD:
- Escribe un Unit Test que falle. (Sí, leíste bien: el Test F-A-L-L-A-R-Á).
- Escribe lo mínimo de código para que el test pase.
- Refactoriza el código. Si algo se rompe, ten la confianza de que el unit test te lo hará saber :)
A diferencia del escultor que termina la escultura cuando se siente satisfecho con esta, a través de la tecnología nosotros nos asemejamos a la naturaleza, la cual sigue trabajando en su obra y mejorándola con cada iteración. #kaizen
Nota: si descubres que existen mejoras que se pueden realizar a este artículo, por favor déjame saber…para planificar la refactorización :)
Keep on learning and refactoring.
Como siempre, por favor déjame tu feedback en un comentario en este artículo. ¿Te fue útil?¿Qué aumentarías o quitarías?¿Otras sugerencias? También puedes enviarme un tweet a @jjruescas1 y colocar #DevOps al final para poder encontrarlo.🙂
¿Deseas conocer más sobre DevOps? No olvides revisar el curso “DevOps — Las Artes Marciales del Software” en Udemy.com.