Evita la optimización temprana
Todos/as hemos caído en la trampa de meternos en un proceso de optimización que nos ha llevado una pila de tiempo pero que al final, o no ha servido para mucho, o directamente no se ha conseguido lo que pretendía.
En relación a esto existe la famosa frase de Donald Knuth, "Premature optimization is the root of all evil". Esta frase es aproximadamente de los años 60 y todavía tiene vigencia a día de hoy.
Ojo, la frase se refiere en específico a las optimizaciones tempranas. Esto lo digo porque mucha gente la ha malinterpretado o la ha llevado al extremo, pensando que cualquier optimización en el código es mala.
Se suele decir que Ya no se optimiza como antes porque antaño era indispensable optimizar para poder ejecutar los programas en los rudimentarios equipos que había. Hoy en día es al revés, como sobra rendimiento, cada vez se crean más capas y abstracciones sobre el código.
Las optimizaciones tempranas
Las optimizaciones tempranas se suelen dar cuando se quieren optimizar cosas por si acaso, recuerda, No implementes cosas por si acaso 🚧. Mantén el código simple 🚧 y Modulariza más tarde 🚧.
Otro problema con las optimizaciones tempranas es cuando no están medidas, no se sabe bien dónde está el cuello de botella (lo mismo ni hay), es por eso que es recomendable no optimizar nada que no esté medido y que no se sepa su impacto.
Las optimizaciones tempranas pueden llevar a las apariciones de Los espíritus de la complejidad, dando lugar a código mucho más complejo, con más bugs y errores si no se tienen tests. Dependiendo de los resultados puede que no merezca la pena la inversión de horas, sobre todo si empeora el código.
Y es que el código realmente optimizado al extremo es difícil de mantener, ya que muchas veces se hace uso de código de bajo nivel, punteros, acceso a memoria, etc.
De no ser que sea algo muy crítico para negocio, siempre es preferible el código legible y mantenible a código de bajo nivel con más rendimiento. Ojo, obviamente el código con alto rendimiento también puede ser código muy simple y legible, no es incompatible.
No todas las optimizaciones son malas
Como todo en la vida, hay casos y casos. Si lo que se quiere optimizar es una cosa que va a llevar muy poco tiempo, se puede considerar, el problema es cuando nos ponemos a cambiar a lo loco partes importantes del código.
Por ejemplo el código encargado de calcular la iluminación de una escena en un videojuego es muy crítico porque se ejecuta muchas veces en un segundo, optimizar esta parte tiene sentido porque vas a conseguir una mejora sustancial del rendimiento del juego.
Intentar no optimizar de forma temprana no te da la excusa de hacer el código mal a propósito, siempre hay que buscar el buen diseño y arquitectura para que no acabe pasando factura en el futuro.
Tampoco está de más aprender el rendimiento de algoritmos más populares y de las funciones y métodos que usamos en el lenguaje con el que estamos programando, siempre es bueno escoger el adecuado para cada situación.
Algunas conclusiones
La pregunta entonces es, ¿cuál es una optimización prematura y cuál es una bien hecha? Pues dependerá de muchos factores: de la situación, del equipo, de negocio, etc.
De todas formas aquí te dejo algunos ejemplos, de lo que yo generalmente opino que es prematuro o que no:
- Optimizar algo no crítico y que se pierda legibilidad y mantenibilidad en el código: prematura.
- Optimizar algo durante semanas y que suponga una mejora del 5%: prematura.
- Optimizar algo con la excusa de que quizás en un futuro lejano el producto se vuelve viral y lo usan millones de personas: prematura.
- Optimizar algo durante unas horas y que suponga una mejora sustancial sin perder legibilidad: optimización bien hecha
- Optimizar algo que no lleve demasiado tiempo haciendo el código más simple y mantenible: optimización bien hecha.
Si te ha gustado el artículo y no te quieres perder lo nuevo me puedes seguir:
Me puedes decir cualquier cosa por email ¡me encanta leer vuestros mensajes!
hola [arroba] diegologs.com