Los problemas que surgen en el proceso de producción están atrayendo gradualmente la atención de la dirección media y alta. Ya sea desarrollador o arquitecto, debe prestar suficiente atención a los siguientes elementos para evitar meterse en situaciones embarazosas en el futuro. También puede utilizarlo como nota de solución de problemas.
#1. No externalice las propiedades de configuración en archivos de propiedades o archivos XML. Por ejemplo, la cantidad de subprocesos utilizados por el procesamiento por lotes no está configurada para ser configurable en el archivo de propiedades. Su programa por lotes puede ejecutarse sin problemas, ya sea en un entorno DEV o en un entorno UAT (Prueba de aceptación del usuario), pero una vez implementado en PROD, cuando se usa como un programa de subprocesos múltiples para procesar conjuntos de datos más grandes, se generará una IOException. , ya sea debido a diferentes versiones del controlador JDBC o al problema comentado en el punto 2. Si la cantidad de subprocesos se puede configurar en un archivo de propiedades, resulta muy fácil convertirla en una aplicación de un solo subproceso. Ya no necesitamos implementar y probar aplicaciones repetidamente para resolver problemas. Este método también es adecuado para configurar URL, servidor y número de puerto, etc.
# 2. El tamaño del conjunto de datos utilizado en la prueba es inadecuado. Por ejemplo, un escenario típico durante la producción es utilizar solo de 1 a 3 cuentas para las pruebas, cuando el número debería ser de 1000 a 2000. Al realizar pruebas de rendimiento, los datos utilizados deben ser reales y no recortados. Las pruebas de rendimiento que no se aproximan al entorno real pueden generar problemas de rendimiento, expansión y subprocesos múltiples impredecibles. Sólo probando la aplicación con un conjunto de datos más grande se puede garantizar que funciona correctamente y cumple con los SLA (estándares de nivel de servicio) para atributos no funcionales.
#3. Cree ingenuamente que los servicios externos e internos llamados en la aplicación son confiables y siempre están disponibles. No permitir tiempos de espera y reintentos de llamadas de servicio afectará negativamente la estabilidad y el rendimiento de la aplicación. Se requieren pruebas adecuadas de interrupción del servicio. Esto es importante porque las aplicaciones actuales están en su mayoría distribuidas y orientadas a servicios, lo que requiere una gran cantidad de servicios de red. Solicitar interminablemente servicios no disponibles puede dañar su aplicación. También es necesario probar el equilibrador de carga para garantizar que funcione correctamente para mantener cada nodo equilibrado.
# 4. No se siguen los requisitos mínimos de seguridad. Como se mencionó anteriormente, los servicios de red son omnipresentes, lo que facilita que los piratas informáticos los exploten para ataques de denegación de servicio. Por lo tanto, cuando utilice Secure Sockets Layer, debe completar una verificación básica y realizar pruebas de penetración utilizando herramientas como Google skipfish. Una aplicación insegura no sólo amenaza su propia estabilidad, sino que también puede afectar negativamente la reputación de una empresa debido a problemas de integridad de los datos, como una situación en la que el cliente "A" puede ver los datos del cliente "B".
#5. No hay pruebas de compatibilidad entre navegadores. Las aplicaciones web actuales son en su mayoría aplicaciones ricas de una sola página que utilizan el lenguaje de programación JavaScript y marcos como angular js. Para que el sitio web que cree funcione sin problemas en diferentes dispositivos y navegadores, debe implementar el diseño correspondiente. Por lo tanto, para garantizar que su aplicación funcione en todos los dispositivos y navegadores, se debe probar su compatibilidad.
#6. No externalizar reglas comerciales que puedan cambiar con frecuencia. Por ejemplo, leyes fiscales, requisitos gubernamentales o relacionados con la industria, taxonomías, etc. Puede utilizar un motor como Drools para procesar reglas comerciales, lo que le ayuda a externalizar estas reglas comerciales almacenándolas en una base de datos o en Excel. Una vez que las empresas dominan estas reglas comerciales, pueden responder rápidamente a las leyes tributarias o requisitos relacionados con cambios y pruebas mínimos.
#7. Los siguientes documentos no se proporcionan
Además de COS (Condiciones de satisfacción), un formulario creado por MindMap, existen dos formularios de documentos principales en desarrollo ágil , 1 y 2.
#8. No tener un plan de recuperación ante desastres y una estrategia de archivo y monitoreo del sistema adecuados. A medida que se acercan los plazos del proyecto, estas cosas a menudo se pasan por alto en las prisas por implementar el proyecto. No contar con un monitoreo adecuado del sistema con Nagios y Splunk no solo amenaza la estabilidad de su aplicación, sino que también obstaculiza los diagnósticos actuales y los esfuerzos de mejora futuros.
#9. No existe un diseño de columna conveniente para la tabla de la base de datos , como create_datetm, update_datetm, create_by, update_by y timestamp. Tampoco proporciona columnas de registro de eliminación ordenada, como la columna "eliminado" que puede tomar "Y" o. 'N'. O puede tomar la columna 'record_status' de 'Activo' o 'Inactivo'.
#10. No desarrollar un plan de retroceso adecuado. Como resultado, cuando el sistema falla, no hay forma de restaurarlo al estado estable antes de la implementación. Este plan debe ser considerado cuidadosamente y firmado por el equipo correspondiente. Los planes incluyen volver a una versión anterior del software, eliminar todos los datos insertados en la base de datos y todas las entradas en el archivo de propiedades.
#11. No desarrollar un plan de capacidad antes de que comience el proyecto. Hoy en día, al describir los requisitos de la plataforma, no basta con decir simplemente "requiere una computadora Unix, un servidor de base de datos Oracle y un servidor de aplicaciones JBoss". Su solicitud debe ser precisa.
El número 12 a continuación proviene de un comentario de "David DeCesare" de "java.dzone",
#12. "No utilices la mejor herramienta para el trabajo". En muchos casos, los desarrolladores utilizarán un lenguaje o herramienta que quieran aprender en un sistema de producción. Normalmente esta no es la mejor opción. Por ejemplo, usar bases de datos NoSQL para datos que ya son relacionales. Recuerde, no importa qué herramienta adopte, necesitará mantener su producto durante los próximos 3 a 5 años (o incluso más).
#13. Falta de reservas de conocimiento suficientes en 16 áreas técnicas clave. Estas áreas incluyen identificar y solucionar 1) "problemas de concurrencia", 2) problemas de transacciones y 3) problemas de rendimiento. En muchas entrevistas, me basé en estos tres aspectos del conocimiento para conseguir nuevos contratos.