Sin refactor no hay paraíso

Esta charla la dimos en 2017, pero sigue más vigente que nunca. Porque todos queremos escribir buen código… pero nadie quiere meterse a refactorizar el código viejo. En Idealista, lo hicimos. Muchas veces. Y aprendimos mucho.

Refactor vs Rewrite

Primera pregunta que nos hacíamos: ¿vale la pena rehacer esto desde cero o es mejor refactorizar?

• Refactor: mejora progresiva, mantenemos comportamiento, reducimos riesgo.
• Rewrite: solo si el sistema actual es inestable, inmantenible o impide avanzar.

Spoiler: el 90% de las veces elegimos refactor.

Cómo lo hacíamos en Idealista

1. Análisis previo

   • Qué módulos estaban más acoplados
   • Dónde estaban los “code smells” principales
   • Qué partes necesitaban tests antes de tocarlas

2. Principios aplicables

   • SRP (Single Responsibility Principle)
   • Open/Closed
   • Evitar “Primitive Obsession” y “Shotgun Surgery”

3. Métricas internas

   • Coverage antes/después
   • Tiempo de build
   • Ciclo de revisión
   • Tiempo desde PR hasta merge

4. Buenas prácticas

   • Refactors pequeños y atómicos
   • Pull Requests bien explicados
   • Uso extensivo de code reviews y pair programming

5. Herramientas propias

   • elves: conjunto de scripts y checklists para acompañar el refactor
   • VROK (Visual Review OK): sistema visual interno para validar comportamiento

Caso real: Dibuja tu búsqueda (Android)

Una funcionalidad clave en la app de Idealista que permitía dibujar sobre el mapa para definir zonas de interés. ¿El problema? La primera implementación era frágil, acoplada y difícil de mantener.

Lo que hicimos:

• Dividir la lógica de dibujo, renderizado y búsqueda.
• Crear abstracciones para manejar distintos gestos y respuestas.
• Refactor en fases, sin romper producción.
• Tests automáticos de comportamiento visual.

¿Resultado? Código más simple, testable y mantenible. Y más de una noche de sueño tranquila.

Key Takeaways

1. El refactor es una inversión, no una pérdida de tiempo.
2. Elegir bien entre refactor y rewrite es una decisión estratégica.
3. Principios sólidos hacen que el refactor fluya con menos fricción.
4. Las herramientas internas marcan la diferencia.
5. No hay paraíso en proyectos sin refactor.

Recursos recomendados

• Refactoring – Martin Fowler
• Clean Code – Robert C. Martin
• Working Effectively with Legacy Code – Michael Feathers

Conclusión

Refactorizar no es glamoroso. Pero es lo que hace que un equipo técnico pueda moverse rápido sin miedo. Y cuando lo hacés bien, el código (y el negocio) te lo agradecen.

Notas

Todos hemos tenido que lidiar alguna vez con código legado, en Idealista, la app de Android tiene ya varios años y necesitaba un poco de cariño y mimos ​En esta charla contaremos las venturas y desventuras de cómo tratar con código legado, estrategias para no sufrir (tanto), y cómo darle abrazos y besos a tu proyecto para adaptar tu código a las nuevas necesidades. Trabajaremos sobre Android, aunque muchas de las técnicas, estrategias y consejos son aplicables también para Java (incluso para otros lenguajes)