Pruebas y calidad de código

¿Por qué siempre se critica el código heredado?

Todavía recuerdo con claridad el momento en que, el primer día en mi nueva empresa, recibí el repositorio y abrí el código por primera vez.

4 min de lectura
Imagen de portada de ¿Por qué siempre se critica el código heredado?

Todavía recuerdo con claridad el momento en que, el primer día en mi nueva empresa, recibí el repositorio y abrí el código por primera vez.

Había un archivo de 3.000 líneas con todo tipo de lógica entremezclada. Suspiré sin darme cuenta.

«¿Quién demonios escribió esto así…?»

Sin embargo, unos meses después, un nuevo desarrollador que revisaba mi código tenía exactamente la misma expresión. Entonces lo entendí: el código heredado no es culpa de una sola persona.

Voy a empezar por la conclusión.

El código heredado recibe críticas no porque sea malo, sino porque se ha borrado el contexto en el que fue escrito.

Hoy quiero compartir mi experiencia sobre por qué el código heredado siempre se convierte en objeto de reproches y cómo sufrir menos al enfrentarse a él.


¿Qué es el código heredado? ¿Es diferente del código antiguo?

Aclaremos primero algo: el código heredado no es simplemente «código antiguo».

Por lo que he vivido, el criterio es uno solo: código que da miedo tocar porque no tiene pruebas.

Michael Feathers define el código heredado en su libro «Trabajando eficazmente con código heredado» como «código sin pruebas». Aunque se haya escrito hace solo una semana, si no tiene pruebas y cada modificación te pone el corazón en un puño, es código heredado.

En cambio, incluso un código de hace 10 años puede modificarse tranquilamente si cuenta con pruebas exhaustivas.

Por tanto, la edad no es el problema. La clave es tener o no la confianza de que «si toco esto, nada más se romperá».


¿Por qué siempre se critica el código heredado?

Al organizar las razones, encontré tres principales.

1. La persona que escribió el código ya no está en la empresa

No hay nadie a quien preguntar por qué se hizo así. Si tampoco hay comentarios ni documentación, solo quedan el código y mi imaginación.

2. El contexto ha desaparecido

Casi todo código extrañamente enrevesado tiene una historia: un plazo urgente, requisitos absurdos o una solución para evitar un bug de una versión concreta del sistema operativo.

En aquel momento era la mejor opción, pero esas circunstancias no quedan en el código. Solo queda el resultado, que hoy parece incomprensible.

3. El código ajeno siempre parece extraño

Sinceramente, esta es la razón principal. Mi código me parece natural porque tengo el flujo en la cabeza, pero con el código ajeno hay que seguirlo desde el principio.

Esa frustración sale en forma de «¿por qué lo hizo así?».

Veamos el código de abajo. A primera vista, es un rastro típico de código heredado: uno se pregunta por qué existe esa condición.

// por qué 30 se resta, nadie lo sabe
if user.type == "B" && amount > 0 {
    finalPrice = amount - 30 // 2019residuo de una promoción de años?
}

No hay forma de saber si este - 30 sigue siendo necesario o si es un vestigio de un evento antiguo. Una línea así, acumulada muchas veces, acaba convirtiéndose en código heredado.


Entonces, ¿cómo debemos tratar el código heredado?

Ante un código heredado desconocido es natural querer «reescribirlo todo», pero hay un camino mejor.

Ahora sigo tres principios.

  1. No lo reescribo a la ligera — el código que funciona incorpora la respuesta a innumerables bugs resueltos con el tiempo. Si lo reescribes, tendrás que enfrentarte a ellos de nuevo desde cero.
  2. Primero añado pruebas antes de modificarlo — si fijamos el comportamiento actual con pruebas, veremos enseguida qué se rompe después del cambio.
  3. Dejo constancia de por qué hice el cambio — si explico el motivo en el mensaje del commit o en un comentario, la siguiente persona al menos me culpará un poco menos.

El tercero es especialmente importante. Es la única forma de no transmitir a alguien del futuro la frustración que yo siento ahora.


Al final, el código nuevo de hoy será el código heredado de mañana

Lo que descubrí durante estos seis meses es un poco desalentador: este código que estoy escribiendo con tanto cuidado también será código heredado, criticado por alguien dentro de unos años.

Al aceptarlo, me sentí más tranquilo. En lugar de buscar la perfección, cambié el rumbo hacia facilitarle el trabajo a la siguiente persona.

Si ahora suspiras frente a un código heredado desconocido, recuerda por un momento que quien lo escribió también hizo lo mejor que pudo aquel día. Y empieza tranquilamente por añadir pruebas. Parece el camino que menos daño nos hace a todos.