Rendimiento no siempre es el enemigo. Nombres confusos y diseños enredados sí lo son.
Cuando estamos desarrollando sistemas, es normal que aparezcan problemas y desafíos de todo tipo. Pero hay algo curioso: casi siempre lo primero que queremos atacar es el rendimiento. “¿Esto va a ser rápido?”, “¿Podemos optimizar este loop?”, “¿Cómo reducimos consultas a la base?”.
Sí, el rendimiento importa. Pero seamos honestos: rara vez es el verdadero problema de nuestro código. Lo que de verdad nos hace perder tiempo (y dinero) es otra cosa. Lo digo por experiencia: tarde o temprano en un equipo llega el momento de admitir que hay que reescribir todo porque se volvió inentendible.
Los bugs críticos aparecen porque no entendemos el código, no porque corra lento. La deuda técnica crece porque nadie se anima a tocar algo roto, no porque falte caching.
Entonces, ¿qué deberíamos resolver primero? Para mí es clarísimo:
Elegir buenos nombres. Variables, métodos y clases tienen que decir claramente qué hacen.
Mantener clases y métodos chicos. No hace falta aplicar patrones de diseño desde el día uno. Primero escribí métodos que hagan una sola cosa y clases fáciles de testear.
Revisar el diseño temprano. Un diseño claro y simple se defiende solo. Cuanto más limpio, menos miedo de cambiarlo.
El día que tu equipo tenga que reescribir algo, que sea porque aprendieron algo nuevo del negocio, no porque el código se volvió imposible de leer.
Mi sugerencia: antes de optimizar la performance, optimizá la legibilidad. Eso es lo que de verdad te va a dar ventaja, a vos y a tu empresa.
Me dedico a crear soluciones web eficientes y a compartir mi conocimiento con la comunidad de desarrolladores.
