¡Peligros del proyecto J2EE!

En mis diversos puestos como desarrollador, desarrollador senior y arquitecto, he visto lo bueno, lo malo y lo feo en lo que respecta a proyectos empresariales Java. Cuando me pregunto qué hace que un proyecto tenga éxito y otro fracase, es difícil dar con la respuesta perfecta, ya que el éxito resulta difícil de definir para todos los proyectos de software. Los proyectos J2EE no son una excepción. En cambio, los proyectos tienen éxito o fracasan en diversos grados. En este artículo, mi objetivo es tomar los 10 peligros principales que afectan el éxito de un proyecto empresarial de Java y mostrárselos a usted, el lector.

Algunos de estos peligros simplemente ralentizan el proyecto, algunos son senderos falsos y otros pueden arruinar por completo cualquier posibilidad de éxito. Sin embargo, todos son evitables con una buena preparación, conocimiento sobre el viaje que se avecina y guías locales que conocen el terreno.

Este artículo tiene una estructura simple; Cubriré cada peligro de la siguiente manera:

  • Nombre del peligro: una sola línea que describe el peligro
  • Fase del proyecto: la fase del proyecto donde ocurre el peligro
  • Fase (s) del proyecto afectadas: en muchos casos, los peligros pueden tener un efecto dominó en fases posteriores del proyecto
  • Síntomas: síntomas asociados con este peligro
  • Solución: formas de evitar el peligro por completo y cómo minimizar sus efectos en su proyecto
  • Notas: Puntos que deseo impartir que se relacionan con el peligro, pero que no encajan en las categorías anteriores.

Como se señaló anteriormente, examinaremos cada peligro en el contexto de un proyecto Java empresarial, junto con sus fases importantes. Las fases del proyecto cubren:

  • Selección de proveedor: el proceso de elegir la mejor combinación posible de herramientas antes de comenzar su proyecto J2EE, desde el servidor de aplicaciones hasta su marca de café.
  • Diseño: entre una metodología rigurosa en cascada y un enfoque de "codificarlo y ver", se encuentra mi opinión sobre el diseño: hago suficiente diseño para poder avanzar cómodamente hacia el desarrollo. Considero que mi fase de diseño está completa cuando sé exactamente lo que estoy construyendo y cómo lo construiré. Además, utilizo plantillas de diseño para asegurarme de haber hecho todas las preguntas correctas sobre mí y la solución propuesta antes de pasar al desarrollo. Sin embargo, no tengo miedo de codificar en esta fase; a veces es la única forma de responder una pregunta sobre, digamos, rendimiento o modularidad.
  • Desarrollo: La fase del proyecto donde se mostrará la cantidad de trabajo realizado en fases anteriores. Una buena selección de herramientas junto con un buen diseño no siempre significa un desarrollo súper fluido, ¡pero seguro que ayuda!
  • Prueba de estabilización / carga: en esta fase, el arquitecto del sistema y el gerente del proyecto impondrán una congelación de funciones y se centrarán en la calidad de la construcción, además de garantizar que las estadísticas vitales del sistema (número de usuarios simultáneos, escenarios de conmutación por error, etc.) se puede reunir. Sin embargo, la calidad y el rendimiento no deben ignorarse hasta esta fase. De hecho, no puede escribir código lento o de baja calidad y dejarlo hasta que se estabilice.
  • Live: Esta no es realmente una fase de proyecto, es una fecha grabada en piedra. Esta fase tiene que ver con la preparación. Es donde los fantasmas de los errores pasados ​​volverán para acechar su proyecto, desde un mal diseño y desarrollo hasta una mala elección de proveedores.

La Figura 1 ilustra las fases del proyecto más afectadas por las diferentes causas (y en particular los efectos colaterales).

Bueno, entonces, sin más preámbulos, ¡sumergámonos en el top 10!

Peligro 1: No entender Java, no entender EJB, no entender J2EE

Bien, voy a dividir este en tres subelementos para facilitar el análisis.

Descripción: No entender Java

Fase del proyecto:

Desarrollo

Fase (s) del proyecto afectadas:

Diseño, estabilización, vivo

Características del sistema afectadas:

Mantenibilidad, escalabilidad, rendimiento

Síntomas:

  • Reimplementar la funcionalidad y las clases que ya están incluidas en las API principales de JDK
  • Sin saber qué son algunos o todos los siguientes y qué hacen (esta lista representa solo una muestra de temas):
    • Recolector de basura (tren, generacional, incremental, sincrónico, asincrónico)
    • Cuando los objetos se pueden recolectar como basura - referencias colgantes
    • Mecanismos de herencia utilizados (y sus compensaciones) en Java
    • Método de sobrecarga y sobrecarga
    • Por qué java.lang.String(¡sustituye tu clase favorita aquí!) Resulta malo para el rendimiento
    • Semántica de referencia de paso de Java (versus semántica de valor de paso en EJB)
    • Usar ==versus implementar el equals()método para no primarios
    • Cómo Java programa los subprocesos en diferentes plataformas (por ejemplo, preventivo o no)
    • Hilos verdes versus hilos nativos
    • Hotspot (y por qué las antiguas técnicas de ajuste del rendimiento niegan las optimizaciones de Hotspot)
    • El JIT y cuando los buenos JIT fallan (desarmar JAVA_COMPILERy su código se ejecuta bien, etc.)
    • API de colecciones
    • RMI

Solución:

Necesita mejorar su conocimiento de Java, especialmente sus fortalezas y debilidades. Java existe mucho más allá del lenguaje. Es igualmente importante comprender la plataforma (JDK y herramientas). Concretamente, debería obtener la certificación como programador de Java si aún no lo ha hecho; se sorprenderá de lo mucho que no sabía. Mejor aún, hágalo como parte de un grupo y empuje unos a otros. También es más divertido de esta manera. Además, configure una lista de correo dedicada a la tecnología Java y ¡continúe! (Todas las empresas con las que he trabajado tienen estas listas, la mayoría de las cuales reciben soporte vital debido a la inactividad). Aprenda de sus compañeros desarrolladores: son su mejor recurso.

Notas:

Si usted u otros miembros de su equipo no comprenden el lenguaje de programación y la plataforma, ¿cómo puede esperar construir una aplicación empresarial Java exitosa? Los programadores de Java fuertes adoptan EJB y J2EE como patos al agua. Por el contrario, los programadores pobres o sin experiencia construirán aplicaciones J2EE de baja calidad.

Descripción: No entender EJB

Fase del proyecto:

Diseño

Fase (s) del proyecto afectadas:

Desarrollo, Estabilización

Características del sistema afectadas:

Mantenimiento

Síntomas:

  • EJB que funcionan cuando se llaman por primera vez pero nunca después (especialmente beans de sesión sin estado que se devuelven al grupo listo)
  • EJB no reutilizables
  • No saber de qué es responsable el desarrollador, en comparación con lo que proporciona el contenedor.
  • EJB que no corresponden a la especificación (activar subprocesos, cargar bibliotecas nativas, intentar realizar E / S, etc.)

Solución:

Para mejorar sus conocimientos sobre EJB, tómese un fin de semana y lea la especificación EJB (la versión 1.1 tiene 314 páginas). Luego lea la especificación 2.0 (¡524 páginas!) Para tener una idea de lo que la especificación 1.1 no abordó y adónde lo llevará la especificación 2.0. Concéntrese en las partes de la especificación que le indican a usted, el desarrollador de la aplicación, cuáles son las acciones legales en un EJB. Las secciones 18.1 y 18.2 son buenos lugares para comenzar.

Notas:

No mire el mundo de EJB a través de los ojos de su proveedor. Asegúrese de conocer la diferencia entre las especificaciones que sustentan el modelo EJB y una versión particular de ellas. Esto también garantizará que pueda transferir sus habilidades a otros proveedores (o versiones) según sea necesario.

Descripción: No entender J2EE

Fase del proyecto:

Diseño

Fase (s) del proyecto afectadas:

Desarrollo

Características del sistema afectadas:

Mantenimiento, escalabilidad, rendimiento

Síntomas:

  • El diseño "Everything is an EJB"
  • Gestión manual de transacciones en lugar de utilizar los mecanismos proporcionados por el contenedor
  • Implementaciones de seguridad personalizadas: la plataforma J2EE tiene probablemente la arquitectura de seguridad más completa e integrada en informática empresarial, desde la presentación hasta el back-end; rara vez se utiliza en todas sus capacidades

Solución:

Conozca los componentes clave de J2EE y las ventajas y desventajas que cada componente aporta. Cubra cada servicio por turno; el conocimiento es igual al poder aquí.

Notas:

Solo el conocimiento puede solucionar estos problemas. Los buenos desarrolladores de Java son buenos desarrolladores de EJB, quienes a su vez están en una posición ideal para convertirse en gurús de J2EE. Cuanto más conocimientos de Java y J2EE posea, mejor será en el diseño y la implementación. Las cosas comenzarán a encajar en su lugar en el momento del diseño.

Peligro 2: ingeniería excesiva (para EJB o no para EJB)

Fase del proyecto:

Diseño

Fase (s) del proyecto afectadas:

Desarrollo

Características del sistema afectadas:

Mantenimiento, escalabilidad, rendimiento

Síntomas:

  • EJB de gran tamaño
  • Desarrolladores que no pueden explicar qué hacen sus EJB y las relaciones entre ellos
  • EJB, componentes o servicios no reutilizables cuando deberían
  • Los EJB comienzan nuevas transacciones cuando una transacción existente es suficiente
  • Niveles de aislamiento de datos establecidos demasiado altos (en un intento por estar seguros)

Solución:

La solución para la sobreingeniería proviene directamente de la metodología de programación extrema (XP): diseñe y codifique lo mínimo para cumplir con los requisitos del alcance, nada más. Si bien debe estar al tanto de los requisitos futuros, por ejemplo, los requisitos de carga promedio futuros o el comportamiento del sistema en los momentos de carga máxima, no intente adivinar cómo será el sistema en el futuro. Además, la plataforma J2EE define características como la escalabilidad y la conmutación por error como tareas que la infraestructura del servidor debe manejar por usted.

Con sistemas mínimos, compuestos por pequeños componentes diseñados para hacer una cosa y hacerlo bien, el nivel de reutilización mejora, al igual que la estabilidad del sistema. Además, la capacidad de mantenimiento de su sistema se fortalece y los requisitos futuros se pueden agregar mucho más fácilmente.

Notas:

Además de las soluciones enumeradas anteriormente, emplee patrones de diseño, que mejoran significativamente el diseño de su sistema. El modelo EJB en sí usa patrones de diseño de manera extensiva. Por ejemplo, el

Home

La interfaz de cada EJB es un ejemplo de un patrón Finder y Factory. La interfaz remota de un EJB actúa como un proxy para la implementación real del bean y es fundamental para la capacidad del contenedor de interceptar llamadas y proporcionar servicios como el equilibrio de carga transparente. Ignore el valor de los patrones de diseño bajo su responsabilidad.

Otro peligro contra el que advierto continuamente: usar EJB por el simple hecho de hacerlo. No solo algunas partes de su aplicación podrían modelarse como EJB cuando no deberían serlo, sino que toda su aplicación podría usar EJB sin una ganancia cuantificable. Esto es una ingeniería excesiva llevada a extremos, pero he visto aplicaciones de servlet y JavaBean perfectamente buenas destrozadas, rediseñadas e implementadas usando EJB sin buenas razones técnicas.

Peligro 3: no separar la lógica de presentación de la lógica empresarial

Fase del proyecto:

Diseño

Fase (s) del proyecto afectadas:

Desarrollo

Características del sistema afectadas:

Mantenibilidad, extensibilidad, rendimiento

Síntomas:

  • JSP grandes y difíciles de manejar
  • Te encuentras editando JSP cuando cambia la lógica empresarial
  • Un cambio en los requisitos de visualización lo obliga a editar y volver a implementar EJB y otros componentes de backend

Solución:

La plataforma J2EE le brinda la oportunidad de separar la lógica de presentación de la navegación y el control y, finalmente, de la lógica empresarial. Se llama arquitectura Modelo 2 (consulte Recursos para obtener un buen artículo). Si ya ha caído en esta trampa, se requiere una fuerte dosis de refactorización. Debería tener al menos cortes verticales finos que sean en su mayor parte independientes (es decir, la forma en que solicito un widget es una sección separada de cómo cambio mi nombre de usuario o contraseña). Utilice esta organización implícita de su sistema para refactorizar en etapas.

Notas:

El uso de un diseño coherente junto con un marco de interfaz de usuario (taglibs, por ejemplo) también le ayudará a evitar problemas de separación lógica en su proyecto. No se moleste en construir otro marco GUI para sus propias necesidades, hay demasiadas buenas implementaciones disponibles. Evalúe cada uno de ellos y adopte el marco que mejor se adapte a sus necesidades.

Peligro 4: no implementarse donde se desarrolla

Fase del proyecto:

Desarrollo

Fase (s) del proyecto afectadas:

Estabilización, Paralelo, Vivo

Características del sistema afectadas:

Tu cordura

Síntomas:

  • Transiciones de varios días o de una semana a sistemas en vivo
  • El riesgo que implica la puesta en marcha es sustancial, con muchas incógnitas y escenarios de uso importantes no probados
  • Los datos en los sistemas en vivo no son los mismos que los datos en las configuraciones de desarrollo o estabilización
  • Incapacidad para ejecutar compilaciones en máquinas de desarrollador
  • El comportamiento de la aplicación no es el mismo en los entornos de desarrollo, estabilización y producción.

Solución:

La solución a Danger 4 comienza duplicando fielmente el entorno de producción en su entorno de desarrollo. Desarrolle exactamente con la misma configuración que en la que planea comenzar a funcionar; no desarrolle en JDK 1.3 y Red Hat Linux cuando planee lanzar en JDK 1.2.2 y Solaris 7. Además, no desarrolle en un servidor de aplicaciones y se activa en otro. Además, obtenga una instantánea de los datos de la base de datos de producción y utilícela para realizar pruebas, no confíe en datos creados artificialmente. Si los datos de producción son confidenciales, desensibilícelos y cárguelos. Los datos de producción inesperados se romperán:

  • Reglas de validación de datos
  • Comportamiento del sistema probado
  • Contratos entre componentes del sistema (EJB-EJB y base de datos EJB en particular)

Lo peor de todo es que cada uno de estos dará como resultado excepciones, punteros nulos y comportamientos que nunca antes había visto.

Notas:

Los desarrolladores con frecuencia dejan la seguridad hasta la estabilización ("Sí, las pantallas funcionan, ahora agreguemos el material de validación del usuario"). Evite esta trampa dedicando la misma cantidad de tiempo a implementar la seguridad que a la lógica empresarial.