El día que me puse a borrar código que funcionaba y no me arrepentí

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.

Borrar código que funciona es un riesgo. Hace unos meses borré una clase entera. Funcionaba. Llevaba años en producción sin dar guerra, hacía exactamente lo que se esperaba de ella y nadie se quejaba.

La seleccioné, pulsé suprimir y confirmé. Y me sentí raro, no voy a mentir. Como cuando tiras una camiseta vieja que ya no te pones pero que te trae recuerdos.

Lo curioso es que no me arrepentí. Ni entonces ni ahora. Y darle vueltas a por qué ha terminado en este artículo.

«Funciona» no es lo mismo que «está bien»

Hay una trampa mental en la que caemos todos los que programamos. Asociamos «el código pasa los tests y nadie ha llamado quejándose» con «este código es bueno». Y no son la misma cosa. Ni de lejos.

El código que aquel día borré funcionaba, sí. Pero era una clase de cuatrocientas líneas que nadie entendía. Yo incluido, y la había escrito yo.

Cada vez que había que tocar algo cerca, todos hacíamos lo mismo: rodearla. Como ese mueble que está mal puesto en el pasillo y llevas seis meses esquivando en vez de moverlo.

Ese es el verdadero peligro. No el código que falla, porque ese lo arreglas o lo tiras sin pensarlo. El peligroso es el que funciona pero te tiene secuestrado.

El que nadie quiere tocar por miedo a romper algo que no se sabe muy bien cómo se sostiene.

El coste invisible de conservar

Lo que aprendí con los años es que conservar código tiene un coste, aunque no aparezca en ninguna factura. Cada línea que mantienes vivas es una línea que alguien tiene que entender, mantener, evitar romper. Es deuda. Y la deuda con intereses bajos también se acumula.

Pensamos que borrar es perder. Tiramos trabajo. Tiramos horas. Pero a veces lo que tiramos es justo lo que nos estaba frenando.

«La perfección se alcanza, no cuando no hay nada más que añadir, sino cuando no queda nada más que quitar.»

— Antoine de Saint-Exupéry

Saint-Exupéry lo decía pensando en aviones y en prosa, no en Java, pero le viene como anillo al dedo a esto. Programar bien no es acumular soluciones. Muchas veces es lo contrario: encontrar qué sobra y atreverse a quitarlo. La parte difícil no es técnica, es emocional. Cuesta soltar algo que te costó hacer.

Lo que descubrí al volver a escribirlo desde cero

Cuando borré aquella clase, no la dejé en el vacío. La reescribí. Y la reescritura ocupaba unas ochenta líneas. De cuatrocientas a ochenta. Hacía exactamente lo mismo, pero esta vez se entendía a la primera.

¿Por qué la primera versión era tan monstruosa? Porque había crecido por capas. Un parche aquí, una condición especial allá, un «ya lo limpio luego» que nunca llegó. Cada cambio individual tenía sentido en su momento. El conjunto era un Frankenstein.

Al partir de cero, con el conocimiento que no tenía cuando la escribí por primera vez, todo encajó distinto. A veces el problema no es el código. Es que tú ya no eres el programador que lo escribió, y eso es buena señal.

Un ejemplo de lo que quiero decir

Imagina un método que valida un usuario y que ha ido acumulando ifs con los años. Algo así:

public boolean validar(Usuario u) {
    if (u != null) {
        if (u.getEmail() != null) {
            if (u.getEmail().contains("@")) {
                if (u.getEdad() >= 18) {
                    return true;
                }
            }
        }
    }
    return false;
}

Funciona. Pasa los tests. Pero cada nivel de anidación es un sitio donde esconder un error futuro. La misma lógica, escrita pensando en quitar en vez de en añadir, queda así:

public boolean validar(Usuario u) {
    if (u == null) return false;
    if (u.getEmail() == null || !u.getEmail().contains("@")) return false;
    return u.getEdad() >= 18;
}

No hace nada nuevo. Hace lo mismo, pero ahora se lee de un vistazo. Y si mañana hay que añadir una condición, sabes exactamente dónde ponerla sin rezar para que no se rompa el resto.

Por qué nos cuesta tanto tirar

Creo que el apego al código viejo no es racional. Es sentimental. Le tenemos cariño porque nos costó. Porque representa una noche que nos quedamos hasta tarde, un bug que perseguimos durante días, un momento en el que por fin compiló y dijimos «menos mal».

Tengo una gata en acogida ahora, Toñi, que llegó a casa con año y medio y con sus mañas. Atigrada con tonos naranjas, igualita que Bella, la veterana. Lo de la acogida me enseñó algo que aplica raro pero aplica: a veces lo mejor que puedes hacer por algo que quieres es dejarlo marchar a donde estará mejor. No quedártelo por miedo a que falte.

Con el código pasa parecido. Te aferras a una solución porque fue tuya, porque funcionó cuando lo necesitabas. Pero quedártela «por si acaso» no la hace mejor. Solo la convierte en un peso que arrastras.

Borrar como hábito, no como drama

Desde aquel día borro más a menudo. Y con menos ceremonia. No espero a que algo se convierta en un monstruo de cuatrocientas líneas para reaccionar. Si veo código muerto, código comentado «por si vuelvo a necesitarlo», funciones que nadie llama, fuera. El control de versiones existe precisamente para que no tengas miedo. Si te equivocas, lo recuperas. Nunca borras de verdad.

Eso me quitó el miedo. Saber que git guarda todo me permite ser valiente sin ser temerario. Borro, pruebo, y si la cosa estaba mejor antes, vuelvo. Casi nunca vuelvo.

El código que funciona no es sagrado. Es solo código que aún no ha empezado a estorbar. Y cuando empieza, lo mejor que puedes hacer por tu proyecto, y por el programador que vendrá detrás, que igual eres tú mismo dentro de un año, es atreverte a pulsar suprimir.

Aquella clase llevaba años funcionando. La borré en diez segundos. Y dormí mejor esa noche.

---

Foto: turned-on gray laptop computer por Safar Safarov en Unsplash.