Hola a todos, si están en el desarrollo de software, entonces saben que crear una aplicación es fácil, pero crear una aplicación mantenible que pueda pasar la prueba del tiempo en producción es bastante difícil y esa es la razón principal por la que los desarrolladores de software experimentados reciben salarios más altos en comparación con muchos. otros trabajos. En este artículo, voy a compartir contigo algunos consejos sobre cómo crear aplicaciones Java mantenibles que te ayudarán no solo en el nuevo año, sino también en los próximos años en tu carrera de desarrollo de software. Un aspecto del desarrollo, que los desarrolladores a menudo pasan por alto, es la creación de aplicaciones que sean fáciles de mantener y de soportar.. Dado que el software pasa el 90% de su vida útil en modo de mantenimiento, es muy importante que su aplicación sea fácil de configurar, admitir y mantener.
Además, la aplicación Java no es diferente a cualquier otro software, debe prestar atención a estas propiedades clave de la escritura de código de calidad de producción, por lo tanto, este consejo también se aplica a cualquier lenguaje de programación que se utilice para crear software del mundo real utilizado por usuarios reales.
Si ha trabajado en grandes organizaciones, por ejemplo, bancos de inversión como Barclays, Citibank o grandes compañías de seguros, verá lo importante que es el soporte y el mantenimiento de las aplicaciones de producción.
Hay varios ingenieros de software más que trabajan en roles de soporte que programadores que desarrollan software. Tiene soporte L1, L2 y L3 y luego un equipo de soporte dedicado para cada aplicación. Esto significa que el apoyo es realmente importante.
Pero, cuando los programadores desarrollan una aplicación, se centran en las características y la velocidad de desarrollo, como la rapidez con la que una característica está lista para ser probada, etc., y para lograrlo, muchos programadores, incluido yo mismo en el pasado, a menudo ignoramos las cosas que importan mucho en la producción.
A continuación se ofrecen algunos consejos prácticos para que su aplicación Java sea más fácil de mantener. Recuerde siempre, el costo de mantenimiento es mucho más alto que el costo de desarrollo y es fácil dar una solución, pero es igualmente difícil dar una solución que se pueda mantener, es decir, algo que pueda resistir la prueba del tiempo.
Antes de explicar estos 10 consejos que pueden hacer que su aplicación Java sea más fácil de mantener y de soportar, permítame decirle que yo mismo he cometido muchos de estos errores. Requiere mucha disciplina, trabajo duro y estar atento a la escritura de código de calidad.
A veces tienes que hacer retroceder incluso al líder de tu equipo o los gerentes que aportan puntos como apoyo, que a menudo se pasa por alto.
1. No se trague las excepciones
Evite tragarse las excepciones. El seguimiento de la pila es la información de resolución de problemas más valiosa. En el sistema de producción donde la prioridad es activar el sistema y luego encontrar la causa raíz, estas excepciones son oro, sin ellas, nunca podrá encontrar lo que sucedió con su aplicación en ese momento.
Por otro lado, no imprima el seguimiento de la pila varias veces. Imprimir un seguimiento de pila es un proceso que consume muchos recursos y debe controlarse, es decir, imprime más información mientras se ejecuta en modo DEBUG o INFO y solo imprime información esencial mientras se ejecuta en modo PRODUCCIÓN. Este es un ejemplo de excepción de deglución en Java:
prueba {
// haz algo
} catch (FileNotFoundException fe) {
// no hacer nada
}
Esto también se conoce como un bloque try-catch vacío y muchas herramientas de análisis de código estático como Fortify los detectarán en la etapa inicial de desarrollo. Esto también destaca la importancia del análisis de código estático en el desarrollo de Java. Asegúrese de integrar la herramienta de análisis de código estático como parte de su proceso de compilación.
Si aún no está convencido acerca del análisis estático, lea mi publicación sobre por qué el análisis de código estático es importante , eso le dará más razones para usarlo en su proyecto.
3. Evite la tala excesiva
Este consejo está muy relacionado con el primero y, al principio, puede parecer contradictorio, pero en realidad no lo es, de hecho, ambos se complementan. Cuando ejecuta la aplicación Java en su entorno de desarrollo (PC), a nadie le importa cuál es el nivel de registro que tiene. Vaya a ‘DEPURAR’ o ‘TODOS’ si lo desea. Pero cuando pasa a producción (u otros entornos superiores, por ejemplo, QA o UAT), limite su registro a ‘INFO’ o ‘ERROR’. La tala excesiva tiene 3 impactos principales:
1. Coloca una carga innecesaria en la Aplicación. He visto que el rendimiento de la aplicación se reduce a la mitad debido al registro excesivo.
2. Puede llenar el sistema de archivos muy rápidamente y eso puede crear problemas para su aplicación y otras aplicaciones alojadas en el mismo servidor. Este es un problema grave, especialmente si está alojado conjuntamente con alguna otra aplicación. ¿Sabe lo que sucederá cuando se llene el directorio raíz de ciertos tipos de sistemas Unix? – Así es. Nadie puede iniciar sesión en el host.
3. La resolución de problemas será dolorosa, como buscar una aguja en un pajar (si el tipo de soporte pobre alguna vez logra abrir el archivo de registro).
En resumen, hay que mantener el equilibrio entre el registro excesivo y el registro insuficiente, y para ser honesto, eso también es un arte, que requiere un buen conocimiento tanto de la aplicación como del dominio.
Aquí también es donde entra en juego la experiencia, con la participación de personal de soporte de la propia UAT, que le brindarán valiosos consejos sobre el inicio de sesión y el soporte de la aplicación. Recuerde, la vida se trata de mantener el equilibrio correcto :-). Consulte aquí para obtener más consejos de registro para desarrolladores de Java.
4. No olvide cerrar las conexiones de la base de datos
Esta es una de las razones más comunes de problemas de producción en la última década, pero afortunadamente con los marcos y bibliotecas modernos, este problema en realidad está desapareciendo lentamente (ya que el marco se encarga de abrir / cerrar conexiones).
Sin embargo, asegúrese de “cerrar” siempre la conexión de la base de datos para que se libere de nuevo al grupo. Esta es también una de las mejores prácticas de JDBC, que he compartido con ustedes en mi publicación anterior Las 10 mejores prácticas esenciales de JDBC para programadores de Java. Si aún no lo ha leído, asegúrese de leerlo en 2017.
Un error común es no cerrar la conexión en el bloque “finalmente” de un “intento de captura”. Si hay una fuga de grupo de conexiones, su grupo de conexiones se agotará pronto y su usuario experimentará una lentitud inmediata.
Las mismas reglas se aplican al cierre de sockets y streams. Si no los cierra, se quedará sin recursos muy pronto. A veces, los desarrolladores de Java piensan que han cerrado la conexión pero, en realidad, no estaban cerrados, por lo que debe conocer la forma correcta de cerrar las transmisiones en Java .
Esto es parte de las mejores prácticas generales de gestión de recursos. No para desanimarlo, pero personalmente he descubierto que los desarrolladores de C ++ son excelentes para los desarrolladores de Java en lo que respecta a la gestión de recursos. Están más atentos a cerrar la conexión y liberar recursos, algo que los desarrolladores de Java pueden aprender de los programadores de C ++.
5. No subestime la carga de producción
Si es un desarrollador de Java con experiencia, se habrá dado cuenta de que la mayoría de los problemas se exponen en el entorno de producción en lugar de en el entorno UAT o QA, especialmente los problemas relacionados con la concurrencia. ¿Sabes por qué? debido a la carga de producción.
Es posible que haya escuchado al desarrollador hablando con el personal de soporte que ‘Funciona bien en mi entorno de desarrollo. Pero cuando entró en producción, se estrelló ”.
Sí, es el trabajo del equipo de pruebas de carga probar su aplicación con la producción como una carga. Pero eso no significa que, como desarrollador, escribas código que no se escala bien. Por ejemplo, funciona bien para 1 usuario, pero ¿qué sucede cuando hay 500 usuarios en línea simultáneamente?
El problema se expone brutalmente al escribir código concurrente porque la probabilidad deLa condición de carrera es mucho mayor en producción que en cualquier otro entorno. Por lo tanto, siempre tenga en cuenta la carga de producción y el código.
También debe leer mi publicación sobre las mejores prácticas esenciales de multiproceso y concurrencia para los programadores de Java, si aún no lo ha leído. Eso le ayudará a visualizar algunas de las cosas que no pensaría de otra manera.
6. Evite cargar grandes conjuntos de resultados desde la base de datos
Este es uno de los errores comunes que cometen los programadores Java principiantes e intermedios que no saben de paginación o paginación. Simplemente no puede cargar todos los registros, por ejemplo, pedidos o transacciones desde la base de datos en una llamada. En algunos casos, obviamente, se quedará sin memoria y también es una pérdida de ancho de banda de red, CPU y memoria, ya que es posible que el usuario no necesite todos esos datos.
En segundo lugar, simplemente no puede mantener los datos en su aplicación para siempre porque pueden volverse obsoletos, por lo que debe cargarlos nuevamente.
Entonces, en lugar de cargar todos los registros de una vez, implemente algún tipo de ‘paginación’ y / o ‘carga diferida’ para que no tenga que cargar todo al principio.
Aquí es donde ORM y el marco de almacenamiento en caché como Hibernate ayudan mucho. Simplemente liberan a los desarrolladores de Java de preocuparse por la carga diferida y la paginación. Si desea obtener más información sobre cómo funciona la carga diferida en Hibernate, le sugiero que lea Persistencia de Java con Hibernate o Persistencia de Java de alto rendimiento de Vlad Mihalcea, ambos son excelentes libros que todo desarrollador de Java que use Hibernate debería leer.
7. Evite los parámetros de configuración de codificación rígida
Es posible que haya escuchado este consejo varias veces, pero se sorprendería si observa el código escrito por muchos ingenieros de software y programadores profesionales. Apenas hay un código donde algo no está codificado de forma rígida, pero los valores de configuración de codificación rígida como URL, ubicaciones de directorio, nombre de usuario / contraseñas, tamaños de caché, niveles de registro, etc., en el código dan como resultado aplicaciones Java difíciles de mantener.
En lugar de codificar los parámetros de configuración, debe externalizarlos en un archivo de propiedades . Parece bastante simple, pero lo he visto una y otra vez que de alguna manera algún valor codificado se cuela y se rompe cuando pasa a producción. En una palabra, administrar la información de configuración dentro del código es una pesadilla. Nunca hagas eso.
También hay una otra cara, donde muchos programadores simplemente crean demasiados archivos de propiedades con la esperanza de generalizar todo. Tiene sentido mantener las propiedades relacionadas en un solo lugar, por ejemplo, si varias aplicaciones comparten un par de parámetros de configuración, entonces externalícelos en un archivo de propiedades como. bases de datos y URL de middleware, nombre de usuario, contraseña, etc. y deje que otra aplicación importe ese archivo, pero si lo hace por encima de un límite, se convierte en una pesadilla de mantenimiento.
Tampoco debe mezclar nunca los parámetros de configuración relacionados con el entorno, por ejemplo, URL, directorios, nombre de usuario / contraseña con parámetros relacionados con la aplicación, por ejemplo, parámetros de configuración para habilitar y deshabilitar algunas funcionalidades.
Es mejor mantener archivos de propiedades separados para las propiedades de la aplicación y las propiedades del entorno. De esta manera, tendría propiedades de una aplicación en todo el entorno, lo cual es esencial para las pruebas y el lanzamiento de producción.
8. No escriba código específico de la plataforma
A muchos programadores de Java simplemente no les importa una mierda escribir código específico de la plataforma, pensando que Java es independiente de la plataforma. Aunque Java es independiente de la plataforma , si no tiene cuidado, acabará haciendo que su aplicación Java dependa de la plataforma. Los programadores de Java no deben codificar nada que esté relacionado con el sistema operativo local. Por ejemplo, ejecutando un comando de Linux (ejemplo: uname -a ) desde java y manejando la salida.
Esto no funcionará siempre que su empresa decida migrar a Windows desde Unix y será doloroso refactorizar cientos de líneas de código que contengan dicho código. Este es nuevamente el caso donde el análisis de código estáticote puede ayudar mucho. Asegúrese de integrar herramientas como Sonar o Fortify en su proceso de compilación para escanear regularmente el código en busca de tales olores de código.
9. Considere la posibilidad de agrupar
Esta es un área en la que incluso muchos programadores experimentados de Java también fallan. Dado que no todas las aplicaciones se ejecutan en el clúster, es posible no pensar en la agrupación en clústeres al principio, pero si alguna vez decide ejecutar su aplicación en un clúster en la etapa posterior de desarrollo, sería muy difícil refactorizar su aplicación.
Por ejemplo, si tiene un trabajo programado dentro del código, ¿qué pasará con él si ejecuta varias instancias de la misma aplicación? ¿No se ejecutaría varias veces? ¿Cuáles son los efectos secundarios de esto?
Es mejor pensar en agrupar al inicio del desarrollo y evitar programar trabajos directamente desde el código Java, pensar en usar herramientas más útiles como Autosys para la programación y el monitoreo de trabajos.
10. Evite empaquetar varias versiones de los mismos archivos JAR
Empaquetar archivos jar de utilidad en varios lugares, especialmente varias versiones del mismo jar de utilidad en varias ubicaciones, es la causa de muchos problemas de producción.
Debe tener una compilación limpia y un procesamiento de versiones, especialmente para aplicaciones internas. Considere usar Maven para la administración de dependencias, hace la vida mucho más fácil que mantener archivos JAR versionados en la carpeta lib.
La infame ‘ClassCast Exception’ o ‘NoClassDefFoundException’ se debe la mayor parte del tiempo a la falta de coincidencia de versiones de los archivos jar de terceros. Asegúrese de empaquetar solo una copia del archivo jar y su compilación sea consistente en entornos como Dev, QA, UAT, etc.
También es una buena práctica mantener la configuración separada de los binarios para que pueda liberar los mismos binarios en todo el entorno, por ejemplo, promoviendo el mismo binario de UAT a Producción después de probar con éxito.
Se trata de algunos consejos prácticos sobre cómo hacer que su aplicación Java sea fácil de soportar y mantener . Estas pequeñas cosas pueden marcar una gran diferencia cuando se trata de desarrollar y mantener una aplicación Java del mundo real. Si aspira a convertirse en arquitecto de soluciones o arquitecto Java, prestar atención a estos detalles le ayudará a presentar su caso con más firmeza. Un buen arquitecto de Java se asegurará de que la aplicación sea fácil de mantener y soportar.