Make it Work, Make it Right: La Madurez de Reescribir tu Propio Código
La trampa de la ansiedad
Todos los que escribimos código conocemos esa sensación. Tenemos una idea brillante para una nueva funcionalidad, abrimos el editor y la ansiedad por verla en pantalla se apodera de nosotros.
La fase de prototipado sirve para validar ideas rápidamente, pero dejar código "atado con alambre" es un riesgo a futuro.
Para no perder el ritmo, empezamos a tomar atajos. Simulamos (mockeamos) una respuesta de la API para ir más rápido, usamos un any en esa interfaz de TypeScript que nos está frenando la compilación, concentramos toda la lógica de negocio adentro del mismo componente visual y dejamos el manejo de errores para "más adelante".
Apretamos guardar, el navegador recarga y... funciona. La dopamina nos invade. Hacemos un par de pruebas rápidas por el happy path (el camino donde todo sale bien), nos convencemos de que está listo para producción y lo subimos.
Semanas después, un usuario hace un clic extraño, un dato llega nulo y la aplicación entera se rompe por un bug silencioso. En ese momento, mirando el código que escribimos hace un mes, nos cae la ficha: no estaba terminado, era solo un prototipo atado con alambre.
El mantra de Kent Beck
Este ciclo de entusiasmo, atajos y arrepentimiento no es un defecto exclusivo de unos pocos; es una condición casi inherente al desarrollo de software. Para lidiar con esto, Kent Beck (uno de los padres de la ingeniería de software moderna) popularizó una filosofía que resume el ciclo de vida ideal del código:
"Make it work, make it right, make it fast." (Hacerlo funcionar, hacerlo bien, hacerlo rápido).
El problema de la mayoría de nosotros es que nos detenemos en el paso uno.
Paso 1: Make it work (La trampa de la dopamina)
Hacer que las cosas funcionen rápido no está mal. De hecho, es vital. Escribir código desordenado al principio es una excelente manera de validar si nuestra idea tiene sentido, si la experiencia de usuario es buena y si estamos resolviendo el problema correcto.
El error no es escribir código "sucio", el error es creer que porque la pantalla muestra lo que queremos, el trabajo de ingeniería está terminado.
Paso 2: Make it right (El autocriterio)
Acá es donde entra en juego la verdadera madurez profesional. Es ese momento exacto donde la funcionalidad ya anda, la dopamina nos dice "pasemos a otra cosa", pero decidimos frenar la pelota.
Dar un paso atrás, mirar nuestro propio código desde afuera y tener la humildad de admitir: "Okay, la idea funciona, pero esto necesita una mejor arquitectura".
Refactorizar ("hacerlo bien") implica tomarse el tiempo de estructurar el código para que sea escalable y mantenible.
"Hacerlo bien" significa desarmar ese prototipo que tanto nos costó armar. Implica sentarnos a tipar estrictamente las interfaces, separar la lógica en servicios o stores, aislar los componentes visuales, escribir los tests básicos y manejar los errores de red. Es un trabajo que el usuario final nunca va a ver, pero que es la garantía para que el sistema no colapse el mes que viene.
La disciplina de frenar
Desarrollar software de calidad requiere pelear constantemente contra nuestra propia ansiedad. Exige cultivar un autocriterio lo suficientemente fuerte como para no enamorarnos de nuestra primera solución.
La próxima vez que veamos nuestro código funcionar por primera vez, celebrémoslo. Pero antes de hacer el commit final, recordemos que recién terminamos el borrador. Frenemos, respiremos, y tomémonos el tiempo de hacerlo bien.
