Cuando la optimización no es la solución óptima

connected apps En el mundo de la programación se habla mucho sobre el rendimiento de las aplicaciones que desarrollamos. Un mal rendimiento es una carga para el sistema y un factor muy importante en la experiencia de usuario (UX). Una aplicación sin fallos pero muy lenta, es peor que una aplicación con fallos pero rápida en ejecución.

Para tener el mejor rendimiento en las aplicaciones, recurrimos a diferentes técnicas de optimización de rendimiento (performance tuning). Dependiendo de la tecnología y el tipo de aplicación, podemos aplicar medidas como el uso de memoria caché, llamadas asíncronas, o el uso de índices en la base de datos. Hay una multitud de técnicas conocidas y que pueden dar muy buenos resultados.

Sin embargo, quiero arrojar un poco de luz en aquellas situaciones en las que optimizamos prematuramente.

Todas las técnicas que acabo de mencionar son aplicables en ciertos supuestos. Por ejemplo, si tenemos datos que no cambian mucho entre una y otra llamada al repositorio de datos, guardarlos en la memoria caché por un tiempo es una buena solución. Sin embargo, en un escenario de datos volátiles y cambiantes como la información bursátil, usar caché nos daría más problemas de los que resolvería.

¿Y cómo sabemos qué optimización conviene?

Aquí está el proverbial quid de la cuestión: no lo sabemos a priori. Igual que no tenemos una bola de cristal para predecir los requerimientos que van a cambiar en una aplicación, tampoco podemos predecir que optimización será la óptima para una aplicación hasta que no nos encontramos en la situación que requiere optimización.

No es mi intención defender que no se haga la optimización de las aplicaciones, todo lo contrario. Creo que la mejor optimización pasa por diseñar la aplicación de manera más adecuada para lo que tiene que hacer, incluso antes de escribir la primera línea de código. Lo que defiendo es que las micro-optimizaciones que solemos hacer mientras desarrollamos la aplicación son a menudo más una fuente de problemas que solución que nos ayuda a tener una aplicación con buen rendimiento.

Lo decía una eminencia de la informática como Donald Knuth: “El problema real es que los programadores se han gastado mucho tiempo pensando sobre la eficiencia en los momentos y sitios equivocados, la optimización prematura es la fuente de todo el mal (al menos la mayor parte de él) en la programación.” (Computer Programming as an Art, 1974).

¿Cómo sería una optimización prematura, entonces?

Por ejemplo, podemos hacer una aplicación web que se lanza periódicamente y envía notificaciones a los usuarios cuando ocurre algún cambio en los datos de los mismos. Podríamos optimizar la aplicación para minimizar su tiempo de ejecución y el acceso a los datos, y es cierto que ganaríamos mucho, pero, ¿y si el verdadero problema está en que estamos intentando meter una aplicación web con calzador en un escenario que no es el adecuado?

La optimización adecuada sería hacer un servicio de Windows que esté haciendo la “escucha” de los datos. Nos quitamos de un plumazo todos los problemas asociados con una aplicación web de llamadas reentrantes y ejecución múltiple. Es decir, micro-optimizando una aplicación a veces no es la solución. Hacer que una aplicación equivocada funcione mejor está mal, porque nos puede enmascarar el verdadero problema de planteamiento de la solución.

¿Qué quiero decir con todo esto? En el fondo, trato de señalar que las aplicaciones no son sistemas sencillos que se pueden optimizar siguiendo unos patrones establecidos de manera ciega. Es preciso comprender las implicaciones y limitaciones del escenario en el que nos movemos, poder plantear alternativas y evaluar honestamente sus puntos fuertes y débiles. Sólo entonces podremos decidir la mejor alternativa para esa aplicación en ese momento de su vida.

De hecho, es una de las razones por las que considero que el arte de programar es precisamente eso, un arte, y no una ingeniería precisa. Es necesario el criterio humano, imperfecto pero que tiene en cuenta una multitud de factores. Por ello, la profesión del arquitecto de software no es tanto sobre el “cómo” sino sobre el “por qué” y “cuándo”.

Edin Kapić