Sobre optimización de aplicaciones

Acerca de la optimización prematura de aplicaciones hay tres citas famosas que copiaré a continuación:

• "The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." - Michael A. Jackson
• "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf
• "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

Creo que ya pueden intuir por donde va mi opinión al respecto. Básicamente, la tendencia moderna dentro de la ingeniería de software es escribir código bien diseñado desde el punto de vista del paradigma de programación que se esté utilizando (ej: OOP) y legible, es decir, que sea comprensible para aquellos que lo van a mantener o modificar en el futuro. Por lo tanto, debería ser expresivo, minimizar las duplicaciones y exhibir, idealmente, algunas (o todas) de las cualidades mencionadas aquí.

Esto no quiere decir que uno debe olvidarse del rendimiento de la aplicación. Lo hay que tener es la capacidad de comprender y prevenir aquéllos puntos críticos donde el performance podría verse adversamente afectado. Como bien sabemos, casi todos los sistemas empresariales actuales tienen interfaces a sistemas externos (bases de datos, ERPs, middlewares, legacies, etc). Por lo tanto, hay que tener en cuenta todas estas interacciones, junto con la configuración del application server y de la JVM, pues el rol que juegan en el ámbito del rendimiento suele ser mucho mayor que, por citar algo que comúnmente se menciona, la cantidad de instancias de una determinada clase.

En realidad, lo que se recomienda al diagnosticar y resolver problemas de performance es aplicar un enfoque similar al que explican en este artículo. La idea es eliminar todas las posibles causas externas para un rendimiento subóptimo antes de empezar a revisar el código (asumiendo que el código está bien estructurado y diseñado).

Desde luego, como las suposiciones siempre son peligrosas, todo buen desarrollo debe efecutar pruebas periódicas de stress y rendimiento (de preferencia lo más pronto posible) para encontrar y corregir problemas antes de que exploten en producción. Para esto hay herramientas específicas que se pueden utilizar (load testers, profilers, extensiones de JUnit como JUnitPerf, etc)

En conclusión, mi recomendación (y la de muchas otras personas dentro de la industria), en lo que al desarrollo de aplicaciones empresariales se refiere, va por privilegiar un buen diseño que exprese el dominio del problema o negocio lo mejor posible mediante un código correctamente estructurado y lo más legible posible. Una vez alcanzado este objetivo, los problemas de performance (que siempre los hay) se pueden atacar y resolver con las herramientas adecuadas.