Dejemos de picar código

Tendrías que pensar en la refactorización como una tarea cotidiana, como podría ser dejar el escritorio recogido, en lugar de abordarla como la reforma integral de tu casa.

Miguel A. Gómez · Seguir2 min read · 5 Ago 2023

A Albert Einstein se le atribuye esa célebre cita que afirma que locura es repetir una y otra vez lo mismo esperando resultados diferentes.

Pues resulta que en realidad la frase apareció por primera vez en un folleto de alcohólicos anónimos.

En cualquier caso, y sin importar quién lo dijo, lo cierto es que para poder innovar con soluciones disruptivas a los grandes problemas hace falta dejar de tropezar con la misma piedra.

Picar código de cualquier manera, infravalorando la calidad de tests o subestimando la legibilidad, nos lleva siempre a las mismas excusas:

“Ahora no hay tiempo para hacer tests”

¿Y cómo piensas comprobar que tu código funciona?

“Ya los haremos más adelante”

Si no tienes tests, todos tus demás esfuerzos por implementar una arquitectura hexagonal, domain-driven design, patrones de diseño o cualquier otra cosa, no evitarán que pierdas el control del proyecto.

“En el próximo sprint refactorizaremos”

Tendrías que pensar en la refactorización como una tarea cotidiana, como podría ser dejar el escritorio recogido, en lugar de abordarla como la reforma integral de tu casa.

“Haciendo tests vamos más lentos”

Más lento irás cuando te encuentres fallos en producción y trates de arreglar una cosa mientras rompes otra.

Sin tests, terminarás con un código inmanejable, porque nadie escribe el código idóneo a la primera.

Por más cuidado que pongas, cometerás errores de diseño que solamente se pueden subsanar mediante refactorización permanente, diaria, para lo cual es fundamental tener buenas pruebas.

“Mi jefe no me deja refactorizar”

¿También le pides permiso a tu jefe para poner ese nuevo condicional?

No, ¿verdad?

Pues eso, NO HAY EXCUSAS.

Debemos entender de una vez que sin buenas pruebas automáticas no puede haber calidad en el código.

Lo repetimos para los del fondo porque es importante: sin pruebas automáticas no puede haber calidad en el código.

Los tests son nuestra red de seguridad a la hora de refactorizar o de introducir nuevas funcionalidades en el sistema.

Modificar código que no está respaldado por una sólida batería de pruebas automatizadas es como jugar a la ruleta rusa con todas las balas en la recámara.

Cambiarás una cosa y romperás otra, garantizado.

Además, el código de los tests tiene que ser igual de conciso, expresivo y concreto que el que va a producción.

Un proyecto grande con una sólida cobertura de tests acumula decenas de miles de ellos.

Si su código es intratable, serán una trampa en lugar de una ayuda.

En resumen, programar para la excelencia es mucho más que picar código.