"Dibuja tu búsqueda", una feature de 2016 que sigue viva

Contexto

En una app de inmuebles hay una funcionalidad que el usuario recuerda, dibujar sobre el mapa la zona donde querés vivir. Con el dedo. Una línea alrededor del barrio y listo, esos son los pisos que te interesan.

Era una de las features más queridas de la app de Android. Y también una de las más frágiles.

Problema

La primera implementación funcionaba, pero estaba acoplada. El dibujo, el renderizado en el mapa y la búsqueda eran la misma cosa. Cualquier cambio tocaba tres sitios. Los gestos eran difíciles de probar. Nadie quería meter mano, y el que lo hacía rezaba.

Y la app necesitaba esa feature para crecer. Cuando el producto empezó a pensar primero en mobile, lo que antes era “una pantalla rara” pasó a ser uno de los diferenciales de la app.

Qué decidimos (y qué descartamos)

La pregunta de siempre. ¿Refactorizamos o reescribimos?

Mi regla, que conté después en T3chFest, es refactor casi siempre. Reescribir solo si el sistema es inestable, imposible de mantener o directamente impide avanzar. Esto no era ninguna de las tres. Era feo, pero funcionaba y los usuarios lo querían.

Descartamos la reescritura limpia. Es seductora y casi siempre peor de lo que parece, porque perdés el conocimiento escondido en los bugs ya arreglados.

Cómo lo hicimos

1. Análisis previo. Antes de tocar nada, dónde estaba el acoplamiento y qué partes no tenían tests. Primero se prueba lo que vas a cambiar.
2. Separar responsabilidades. La lógica de dibujo, el renderizado y la búsqueda dejaron de ser una pieza, con principios sencillos como una responsabilidad por clase, abierto a extensión y cerrado a modificación.
3. Abstracciones para los gestos. Una interfaz para manejar distintos gestos y respuestas, en vez de ramas condicionales por todos lados.
4. Fases pequeñas. PRs chicos y bien explicados, uno detrás de otro. Cada paso, desplegable. Nunca teníamos “la rama del refactor” abierta durante meses.
5. Visual review. Un sistema interno para validar a ojo que lo que veía el usuario no cambió. Y scripts y checklists para acompañar cada fase.
6. Medir antes y después. Cobertura, tiempo de build, ciclo de revisión, tiempo de PR a merge.

Resultado

Un código más simple, más fácil de probar y de mantener. Y, textualmente, más de una noche de sueño tranquila.

La feature sigue viva años después. Para un refactor, no hay mejor métrica que esa. Que nadie te recuerde que existió.

Qué haría distinto

Escribiría antes los tests del comportamiento visual. Los hicimos, pero a mitad de camino, y los primeros PRs fueron más arriesgados de lo que me gustaría reconocer.

Y le daría más voz al equipo de diseño desde el principio. Refactorizamos la implementación, pero algunas decisiones de interacción merecían una conversación que dejé para después.