miércoles, 2 de enero de 2008

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.

1 comentario:

Văn Sát dijo...

Hãy đến với sàn giao dịch vận chuyển hàng hóa, chúng tôi là công ty vận chuyển hàng hóa bắc nam hàng đầu hiện nay. Hiện nay chúng tôi đang cung cấp nhiều dịch vụ liên quan đến vận chuyển, vận tải. Tiêu biểu có thể kể đến như dịch vụ vận tải hàng hóa bằng đường bộ, vận tải bằng đường thủy, vận chuyển hàng hóa bằng đường sắt,... Đối với các tỉnh thành chúng tôi có những dịch vụ riêng biệt để phục vụ nhu cầu. Có thể kể đến một vài dịch vụ như dịch vụ vận chuyển hàng đi an giang, vận chuyển hàng hóa đi vũng tàu, vận chuyển hàng đi bắc giang,... Ngoài ra còn rất nhiều dịch vụ khác đang chờ bạn khám phá. Hãy ghé vào để biết thêm thông tin chi tiết nhé.