Hola amante de “pongo esto aquí y ya lo solucionaré”…
Hoy vengo con una reflexión de esas que no hace falta aprender en un curso, porque la vida y tu yo del futuro se encargan de enseñartela:
Sabes ese momento que tienes que resolver un bug… estás ahí ahí pensando que hacer… y dices:
“Bueno… hago esto rápido y que se quede así. Total, si está funcionando”
No estás muy orgulloso de ello… pero mira qué más da, ya está hecho.
…
Y de repente… a las semanas te escribe tu Scrum Master o Product Owner…
“Oye, ¿Qué tal? Mira… es que este desarrollo que hiciste está dando estos problemas… puedes revisarlo”
PAM!!
Y en ese momento te acuerdas de tu yo del pasado… y ¿sabes lo que toca ahora no?
Volver a mirar que era lo que fallaba…
Volver a entender que era lo que hacía…
Y estudiar el caso que está fallando ahora…
Bueno te lo resumo por si no lo has pillado:
Vas a dedicar más tiempo a lo mismo.
PUNTO.
Por eso te voy a dar el mejor y único consejo que necesitas.
Es muy sencillo.
Hazlo bien desde el principio.
Y ahora me dirás….
"Pero es que no hay tiempo."
"Esto es solo una prueba…. Y ya se quedó así."
"Bueno, luego ya lo refactorizamos."
Venga a ver…. Seamos sinceros… y dime la verdad:
¿Cuántas veces ha llegado ese “luego”?
En resumen… te lo voy a poner en una fórmula para que te acuerdes:
Parches hoy = doble trabajo mañana
En programación, como en la vida, lo que dejas “a medias” vuelve, y nadie quiere quedarse medias.
Así que ya sabes…. Ese “parchecito” que hiciste para ir tirando….
✅ Hoy te funciona.
❌ Pero mañana será una pesadilla.
❌ Y pasado mañana, nadie entenderá por qué se hizo así.
❌ Y dentro de un mes, estarás escribiendo sobre ello en StackOverflow como “hotfix urgente que rompió mi código”.
Pero… ¿Y qué es hacerlo bien? ¿Siempre perfecto?
A ver… No, no se trata de perseguir la perfección.
Se trata de pararte a pensar antes de escribir.
De preguntarte:
👉 ¿Esta solución es clara?
👉 ¿Es mantenible?
👉 ¿Encaja bien en la arquitectura del proyecto?
👉 ¿Sigo los principios SOLID?
Porque muchas veces no es falta de tiempo.
Es falta de pausa o pensar.
Y te voy a dar otra frase a lo maestro jedi:
Un buen código no es el que funciona. Es el que sobrevive.
O también dicho… es el código que cuando ves dentro de unos meses no te acuerdas de la persona que hizo ese commit.
Así que ya sabes:
✅ Para.
✅ Piensa.
✅ Diseña.
✅ Y luego escribe.
Hazlo bien de primeras…
Y evitarás hacer el triple de trabajo más adelante.
Hazlo, aunque sea por ahorrarse trabajo el día de mañana.
Y tú, ¿Eres más de “lo dejo así y ya lo arreglo luego”?
¿O ya te ha explotado un parche del pasado?
Nos leemos en una semana. 👨💻