El día que refactoricé código que funcionaba y lo dejé peor

Este artículo puede incluir enlaces de afiliado. Si compras a través de ellos, me llevo una pequeña comisión sin coste extra para ti. Más información.

Había un módulo en uno de nuestros proyectos que llevaba dos años funcionando sin dar un solo problema. Nadie lo tocaba. Hacía lo suyo, devolvía lo que tenía que devolver y se iba a dormir. Y un viernes por la tarde, con la cabeza ya medio fuera de la oficina, lo abrí «solo para echar un vistazo». Tres horas después había roto algo que llevaba veinticuatro meses sin romperse. Enhorabuena, Ricardo.

Esta es la historia de cómo aprendí, a base de meter la pata, que el orden no siempre es una mejora. A veces es solo una manía mía disfrazada de buenas prácticas. A veces, hay que saber cuando no refactorizar.

El código que me ofendía estéticamente

El método en cuestión tenía unas cuantas cosas que me chirriaban. Variables con nombres regulares, un par de condiciones anidadas que se podían simplificar, una lógica que un programador con más prisa que cuidado había dejado ahí hacía años. Funcionaba. Pasaba todos los tests. Estaba en producción sin incidencias.

Pero me ofendía. No técnicamente, sino estéticamente. Lo miraba y sentía esa cosa incómoda de «esto se puede hacer mejor». Y ahí está el problema: confundí «se puede hacer mejor» con «hay que hacerlo mejor». No son lo mismo. Casi nunca lo son.

Empecé a tirar del hilo. Cambié los nombres. Extraje un par de métodos. Y entonces descubrí que aquella condición rara que me parecía un error en realidad cubría un caso límite que solo pasaba una vez al mes, con un tipo de cliente concreto, y que no estaba documentado en ningún sitio. La «fealdad» tenía una razón. Yo no la conocía. Y la borré tan ricamente.

La diferencia entre limpiar y romper

Refactorizar de verdad significa cambiar la estructura del código sin cambiar su comportamiento. Esa es la definición. La palabra clave es sin cambiar su comportamiento. El problema es que muchas veces no sabemos del todo cuál es el comportamiento real, solo el que imaginamos.

Lo que yo hice aquel viernes no fue refactorizar. Fue reescribir según mi gusto un código que no entendía completamente. Y la diferencia entre una cosa y la otra es justo la que separa a un profesional de alguien que solo quiere que las cosas estén bonitas.

«Cualquier tonto puede escribir código que un ordenador entienda. Los buenos programadores escriben código que los humanos pueden entender.»

— Martin Fowler

Fowler tiene razón, claro, pero hay una trampa en cómo lo leemos. El código que yo quería dejar «más entendible» ya lo entendía la persona que lo escribió, y resolvía un problema que esa persona conocía y yo no. La legibilidad no es solo cómo se ve el código. Es cuánto contexto llevas tú cuando lo lees.

Cuándo refactorizar de verdad aporta algo

Después de aquello me hice una regla bastante simple. Antes de tocar código que funciona, me pregunto una sola cosa: ¿esto lo hago porque alguien lo necesita o porque a mí me molesta verlo así?

Si voy a añadir una funcionalidad y el código actual me lo pone difícil, refactorizar tiene sentido. Estoy pagando una deuda para construir encima. Si hay un bug y la estructura me impide encontrarlo, también. Pero si abro un archivo un viernes y lo único que me pasa es que me apetece ordenarlo, eso no es ingeniería. Es ansiedad con teclado.

El truco está en tener una red de seguridad antes de mover nada. Tests que cubran el comportamiento actual, incluido el caso raro que no entiendes. Si vas a cambiar algo, primero asegúrate de que sabes qué hace, no qué crees que hace.

// Antes de tocar nada, escribo un test que captura
// el comportamiento ACTUAL, incluido lo que no entiendo

@Test
void clienteEspecialMantieneDescuentoMensual() {
    Pedido pedido = new Pedido(clienteEspecial, importe(100));
    // No sé por qué, pero el código viejo aplica esto.
    // Lo dejo fijado ANTES de refactorizar.
    assertEquals(importe(85), calculadora.total(pedido));
}

Este test no es bonito. La intención es justamente esa. Antes de «mejorar» nada, dejo clavado el comportamiento que existe hoy, incluso el que me parece un error. Si después de refactorizar ese test se rompe, no he mejorado el código: lo he cambiado. Y son dos cosas muy distintas. Aquel viernes este test no existía, y por eso me enteré del caso límite cuando ya estaba en producción y un cliente llamó enfadado.

La cuenta que no salía

Lo peor no fue el fallo en sí. Fue el lunes, explicando por qué algo que llevaba dos años bien de repente había dejado de estarlo. No hay buena manera de decir «lo toqué porque me apetecía». Aprendí que la frase «estaba refactorizando» no te salva si nadie te había pedido que lo hicieras.

Lo que me enseñó una gata sobre dejar las cosas en paz

Tengo en acogida a Toñi, una atigrada con tonos naranjas de año y medio que se parece bastante a Bella, la veterana de casa. Toñi tiene una manía: cada vez que ordeno los cables de debajo del escritorio, ella va detrás deshaciéndolo. Lo que para mí es orden, para ella es un sistema perfectamente funcional de cosas con las que jugar.

Un día me quedé mirándola tirar de un cable que yo acababa de recoger y pensé que hacíamos lo mismo. Yo veía el código de otro como ella veía mis cables. Un desorden que había que arreglar. Sin preguntarme si aquello ya cumplía una función que yo no veía. La diferencia es que a Toñi le sale gratis y a mí me costó un lunes incómodo.

El impulso de mejorar es bueno. De verdad que lo es. El problema no es querer que las cosas estén mejor, es no distinguir entre lo que está mal y lo que simplemente no es como yo lo haría. Hay código feo que funciona perfectamente y que es mejor dejar tranquilo. Hay código bonito que acabas de escribir tú y que rompe cosas. La belleza, en esto, miente bastante.

Ahora dudo más, y está bien

Hoy, cuando abro un archivo que funciona y me pica el dedo, espero un segundo. A veces el mejor refactor es el que no haces. No porque seas vago, sino porque entiendes que tu necesidad de orden no es lo mismo que las necesidades del proyecto.

Sigo refactorizando, claro. Pero ahora me lo gano. Primero entiendo, después protejo con tests, y solo entonces toco. Y si lo único que me pasa es que algo no me gusta a la vista, lo apunto en un comentario y sigo con lo mío. El código no está ahí para tranquilizarme a mí. Está para que funcione. Toñi, mientras tanto, sigue convencida de que mis cables están mucho mejor por el suelo.

---

Foto: man in blue dress shirt holding silver macbook por Martina Carinci en Unsplash.