Capítulo 10: Refactoring y Courage
Capítulo 10: Refactoring y Courage
Martes de la segunda semana. Carlos y Diego abren el archivo donde vive la lógica de mover tarjetas. Carlos frunce el ceño. Diego lo nota. Es hora de hablar sobre refactoring y por qué hace falta coraje para mejorar algo que ya funciona.
Anterior: Planning Game iteración 2 | Siguiente: Collective Code Ownership
El olor
Carlos y Diego están en pair. Carlos navega, Diego conduce. Antes de empezar la story de mover tarjetas en cualquier dirección, Carlos pide mirar el código existente.
Carlos (TL): “Diego, antes de agregar la nueva funcionalidad, quiero que veamos la lógica actual de mover tarjetas.”
Diego (Dev): “¿Qué tiene? Funciona. Los tests pasan.”
Carlos (TL): “Funciona, sí. Pero mira: la lógica de mover está mezclada con la validación de que la columna existe, con la verificación de límites WIP futuros, y con la actualización del orden. Son cuatro responsabilidades en un solo lugar.”
Diego (Dev): “Pero es poco código…”
Carlos (TL): “Hoy es poco. Cuando agreguemos mover en cualquier dirección y después los límites WIP, va a crecer. Y cada cambio va a tocar todas las responsabilidades al mismo tiempo. Martin Fowler lo llama ‘code smell’: no es un bug, es un indicador de que el diseño puede mejorar.”
El miedo a romper
Diego entiende el argumento intelectualmente, pero tiene una resistencia visceral.
Diego (Dev): “Tengo miedo de tocar algo que funciona. ¿Y si rompemos la demo de la semana pasada?”
Carlos (TL): “¿Cuántos tests tenemos para la lógica de mover tarjetas?”
Diego (Dev): “Seis.”
Carlos (TL): “Si tocamos algo y un test se pone rojo, sabemos exactamente qué rompimos y dónde. Los tests son nuestra red de seguridad. Refactorizar sin tests es temerario. Refactorizar con tests es disciplina.”
Diego (Dev): “Ok. Pero vamos paso a paso.”
Carlos (TL): “Siempre. Refactoring no es reescribir. Es mejorar la estructura sin cambiar el comportamiento. Después de cada cambio, corremos los tests.”
El proceso de refactoring
Carlos guía a Diego a través del refactoring paso a paso.
Primer paso: extraen la validación de que la columna existe en su propia función. Corren tests. Verde.
Diego (Dev): “No cambió nada visible, pero ahora la validación tiene nombre propio.”
Carlos (TL): “Eso es revelar la intención. Antes, la validación estaba escondida dentro de la lógica de mover. Ahora cualquiera que lea el código sabe que hay una validación explícita.”
Segundo paso: extraen la lógica de actualizar el orden de tarjetas en una columna. Corren tests. Verde.
Tercer paso: lo que queda en la función de mover es solo el movimiento puro: cambiar la tarjeta de una columna a otra. Tres responsabilidades claras, cada una con su nombre.
Diego (Dev): “Ahora es obvio qué hace cada parte.”
Carlos (TL): “Y cuando agreguemos mover en cualquier dirección, solo tocamos la función de mover, sin afectar la validación ni el orden.”
Corren todos los tests una vez más. Verde. Empujan al repositorio. CI verde.
Simple Design revisado
Elena se une a la conversación después del almuerzo.
Elena (Dev): “Vi los cambios que hicieron. Me gusta. Pero, ¿no estamos sobre-diseñando? Antes era una función, ahora son tres.”
Carlos (TL): “Buena pregunta. Kent Beck tiene cuatro reglas de Simple Design. La segunda es que el código revela la intención. Antes, para entender qué hacía esa función, tenías que leer todo el cuerpo. Ahora, los nombres de las tres funciones te dicen qué hace cada una.”
Elena (Dev): “¿Y la cuarta regla? Menor número de elementos posible.”
Carlos (TL): “Las reglas tienen prioridad. Revelar intención es más importante que tener menos elementos. Tres funciones claras son más simples que una función confusa, aunque sean más elementos.”
Diego (Dev): “Simple no es poco. Simple es claro.”
Carlos (TL): “Exactamente.”
Courage en la práctica
Carlos aprovecha el momento para hablar de Courage como valor de XP.
Carlos (TL): “Diego, ¿recuerdas el miedo que sentías hace dos horas?”
Diego (Dev): “Sí. No quería tocar nada.”
Carlos (TL): “Ese miedo es natural. Pero en XP, Courage significa hacer lo correcto aunque dé miedo. No es ausencia de miedo, es actuar a pesar de él. Los tests te dieron la confianza para actuar. Sin tests, el coraje sería imprudencia.”
Elena (Dev): “Es como escalar con arnés. El miedo está ahí, pero sabes que si caes, el arnés te sostiene.”
Diego (Dev): “Los tests son el arnés.”
Carlos (TL): “Y el pair programming es tu compañero de escalada. Nadie refactoriza solo en XP. Siempre hay alguien validando tus decisiones en tiempo real.”
El resultado
Al final del día, la story de mover tarjetas en cualquier dirección está completa. La implementación fue casi trivial: gracias al refactoring, solo tuvieron que modificar la función de mover puro, sin tocar la validación ni el ordenamiento.
Diego (Dev): “Si no hubiéramos refactorizado primero, esto habría sido el doble de difícil.”
Carlos (TL): “Eso es lo que Kent Beck llama ‘preparatory refactoring’. Antes de agregar una feature, mejora el diseño para que la feature sea fácil de agregar.”
Ana (PO): “¿Y eso me costó un solo punto?”
Carlos (TL): “Un punto de refactoring que hizo que la feature costara un punto en vez de tres. Inversión neta positiva.”
Ana sonríe. Los números le hablan.
Práctica XP del capítulo
Refactoring: Kent Beck define refactoring como cambiar la estructura del código sin cambiar su comportamiento observable. Es una práctica continua, no un evento. En XP, el equipo refactoriza constantemente: después de cada Green en el ciclo TDD, se preguntan si el diseño puede mejorar. El coraje necesario para refactorizar viene de los tests: sin ellos, cambiar código existente es jugar a la ruleta rusa.
Simple Design: Las cuatro reglas en orden de prioridad: pasa los tests, revela la intención, no tiene duplicación, tiene el menor número de elementos. Un diseño simple no es un diseño mínimo: es un diseño claro.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Valida que el refactoring tiene retorno de inversión |
| Carlos | Navega, guía el refactoring, enseña Simple Design |
| Diego | Conduce el refactoring, supera el miedo a cambiar código |
| Elena | Revisa los cambios, cuestiona constructivamente |
Anterior: Planning Game iteración 2 | Siguiente: Collective Code Ownership