| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos |
Artículo "Buenas prácticas en J2EE. Segunda parte."
Este artículo contiene la segunda parte de un informe que explica técnicas de gran utilidad para el desarrollo con la plataforma J2EE. Aplicando estas técnicas, podemos disminuir la dificultad y el costo de este tipo de desarrollo y mejorar el rendimiento, calidad, flexibilidad y escalabilidad de los sistemas resultantes.
Artículo "Buenas prácticas en J2EE. Segunda parte." (continuación)
5.3. Buena práctica número 14. Respalde sus datos y su entorno de producción Debería tener precaución extrema cuando trabaje con máquinas de producción. Hay pocas cosas que causen un daño mayor que hacer cambios a un entorno de producción. Se puede evitar mucho sufrimiento si se hacen copias de respaldo. Planifique respaldar sus entornos de producción y de desarrollo. Es fácil de hacer y es lo que se debe hacer. Asegúrese de que sus copias de respaldo incluyan archivos de aplicación, de configuración y de datos. Respalde con regularidad y también antes de cada despliegue. Así, en caso de problemas, podrá recuperar fácilmente el último estado bueno. 6. AFINACIÓN (TUNING) Quizás la etapa más descuidada en la mayoría de los proyectos de desarrollo es la de afinación. Esto es sorprendente, pues una de las causas más comunes de fracaso en grandes proyectos de software es un pobre rendimiento. Aunque muchos programadores llevan a cabo algo de afinación no estructurada, muy pocos construyen y ejecutan un plan de rendimiento que funcione. Aunque parte del problema se debe a la falta de buenas herramientas de afinación, esta situación está cambiando. Algunos vendedores están comenzando a incluir buenos servicios de perfilado en Java así como ayudas para la resolución de problemas. 6.1. Buena práctica número 15. Construya un plan de rendimiento Es necesario comenzar con un plan sólido de rendimiento. A continuación se detallan los componentes clave de dicho plan: Criterios. Se debe asegurar que se capturan todos los criterios importantes de rendimiento. Se debería ser lo más específico posible sobre cargas, tiempos y configuraciones. Interesados. Se debería determinar las personas que deben aprobar el plan y las que deben aprobar el producto acabado. Se debería nombrar a un director del plan para que alguien sea responsable del rendimiento de la aplicación. Mitigación de riesgos. El plan de rendimiento es un buen lugar para comenzar a planificar cómo se mitigan los riesgos cuando algo sale mal. Cronograma. Se necesita reservar tiempo suficiente para implementar el plan de rendimiento. Se debería reservar un poco de tiempo durante cada iteración de diseño para solucionar los cuellos de botella asociados a cada caso de uso. También se debería reservar un periodo de tiempo al final del ciclo de desarrollo, normalmente combinándolo con las pruebas. Herramientas. Se debería definir qué herramientas se usarán para analizar y afinar el rendimiento. Estas herramientas ayudarán a simular cargas, perfilar el rendimiento de la aplicación, analizar los resultados y afinar servidores de software individuales como, por ejemplo, motores de bases de datos. Entornos. Si se necesitan simular cargas grandes, se necesitará una red extensa para hacerlo y un software para ejecutarlo. Otra opción es alquilar a consultores tiempo en este tipo de entornos. Personal. Necesita asegurarse de que cuenta con los recursos humanos necesarios para el plan, desde personal de programación a administradores de bases de datos y especialistas en hardware. Casos claves de prueba. Se deberían construir los casos críticos de prueba por adelantado. Después de que se ha construido el plan de rendimiento, éste debe ser aprobado por los interesados, se debe asegurar que se contará con los recursos y se debe ejecutar el plan. Normalmente las metodologías iterativas incluyen etapas que enfatizan el diseño de una solución, su construcción, pruebas y despliegue. Un análisis de rendimiento sólido se extiende por todas estas etapas. Resumiendo, los problemas tardíos de rendimiento han hecho fracasar muchos proyectos, pero si se cuenta con un plan sólido, se tendrá más probabilidades de salir ileso. La planificación de rendimiento es costosa pero las alternativas pueden ser catastróficas.
Ir a la página: 1 2 3 4 5 6 7 8 Siguiente >>
Versión para imprimir
| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos| |