Dangers du projet J2EE!

Au cours de mes différents mandats en tant que développeur, développeur senior et architecte, j'ai vu le bon, le mauvais et le laid quand il s'agit de projets Java d'entreprise! Quand je me demande ce qui fait qu'un projet réussit et un autre échoue, il est difficile de trouver la réponse parfaite, car le succès s'avère difficile à définir pour tous les projets logiciels. Les projets J2EE ne font pas exception. Au lieu de cela, les projets réussissent ou échouent à des degrés divers. Dans cet article, je vise à prendre les 10 principaux dangers qui affectent le succès d'un projet Java d'entreprise et à les présenter pour vous, le lecteur.

Certains de ces dangers ralentissent simplement le projet, certains sont de fausses pistes, et d'autres encore peuvent carrément ruiner toute chance de succès. Cependant, tout est évitable avec une bonne préparation, des connaissances sur le voyage à venir et des guides locaux qui connaissent le terrain.

Cet article est de structure simple; Je couvrirai chaque danger comme suit:

  • Nom du danger: une seule ligne décrivant le danger
  • Phase de projet: la phase de projet où le danger survient
  • Phase (s) du projet affectée: dans de nombreux cas, les dangers peuvent avoir un effet d'entraînement sur les phases ultérieures du projet
  • Symptômes: symptômes associés à ce danger
  • Solution: moyens d'éviter complètement le danger et comment minimiser ses effets sur votre projet
  • Remarques: les points que je souhaite communiquer qui se rapportent au danger, mais qui ne rentrent pas dans les catégories précédentes

Comme indiqué ci-dessus, nous examinerons chaque danger dans le contexte d'un projet Java d'entreprise, ainsi que ses phases importantes. Les phases du projet couvrent:

  • Sélection du fournisseur: le processus de sélection de la meilleure combinaison d'outils possible avant de démarrer votre projet J2EE - du serveur d'application jusqu'à votre marque de café.
  • Design: Entre une méthodologie rigoureuse en cascade et une approche de «coder et voir», se trouve ma vision du design: je fais suffisamment de design pour pouvoir passer confortablement au développement. Je considère ma phase de conception terminée quand je sais exactement ce que je construis et comment je vais le construire. De plus, j'utilise des modèles de conception pour m'assurer que j'ai posé toutes les bonnes questions à moi-même et à ma solution proposée avant de passer au développement. Cependant, je n'ai pas peur de coder dans cette phase; c'est parfois la seule façon de répondre à une question sur, par exemple, les performances ou la modularité.
  • Développement: La phase du projet où la quantité de travail effectué dans les phases précédentes montrera. Un bon choix d'outils associé à une bonne conception ne signifie pas toujours un développement ultra-fluide, mais cela aide certainement!
  • Stabilisation / Test de charge: dans cette phase, l'architecte système et le chef de projet imposeront un gel des fonctionnalités et se concentreront sur la qualité de la construction, tout en s'assurant que les statistiques vitales du système - nombre d'utilisateurs simultanés, scénarios de basculement, etc. peut être rencontré. Cependant, la qualité et les performances ne doivent pas être ignorées avant cette phase. En effet, vous ne pouvez pas écrire du code de mauvaise qualité ou lent et le laisser jusqu'à la stabilisation pour corriger.
  • Live: Ce n'est pas vraiment une phase de projet, c'est une date gravée dans le marbre. Cette phase concerne la préparation. C'est là que les fantômes des erreurs passées reviendront hanter votre projet, d'une mauvaise conception et développement à un mauvais choix de fournisseurs.

La figure 1 illustre les phases du projet les plus affectées par les différentes causes (et en particulier les effets d'entraînement).

Eh bien, sans plus tarder, plongeons-nous dans le top 10!

Danger 1: ne pas comprendre Java, ne pas comprendre EJB, ne pas comprendre J2EE

Bon, je vais diviser celui-ci en trois sous-éléments pour une analyse plus facile.

Description: ne pas comprendre Java

Phase du projet:

Développement

Phase (s) du projet affectée:

Conception, stabilisation, en direct

Caractéristiques du système affectées:

Maintenabilité, évolutivité, performances

Symptômes:

  • Réimplémentation des fonctionnalités et des classes déjà contenues dans les API principales du JDK
  • Ne sachant pas ce que tout ou partie des éléments suivants sont et ce qu'ils font (cette liste ne représente qu'un échantillon de sujets):
    • Garbage collector (train, générationnel, incrémentiel, synchrone, asynchrone)
    • Quand les objets peuvent être récupérés - références pendantes
    • Mécanismes d'héritage utilisés (et leurs compromis) en Java
    • Méthode de dépassement et de surcharge
    • Pourquoi java.lang.String(remplacez votre classe préférée ici!) Se révèle mauvais pour la performance
    • Sémantique de référence pass-by de Java (versus sémantique de valeur pass-by dans EJB)
    • Utiliser ==ou implémenter la equals()méthode pour les non-primitifs
    • Comment Java planifie les threads sur différentes plates-formes (par exemple, préemptives ou non)
    • Fils verts et threads natifs
    • Hotspot (et pourquoi les anciennes techniques de réglage des performances annulent les optimisations Hotspot)
    • Le JIT et quand les bons JIT tournent mal (non définis JAVA_COMPILERet votre code fonctionne très bien, etc.)
    • L'API Collections
    • RMI

Solution:

Vous devez améliorer vos connaissances sur Java, en particulier ses forces et ses faiblesses. Java existe bien au-delà du langage. Il est tout aussi important de comprendre la plateforme (JDK et outils). Concrètement, vous devriez devenir certifié en tant que programmeur Java si vous ne l'êtes pas déjà - vous serez étonné de voir à quel point vous ne saviez pas. Mieux encore, faites-le en groupe et poussez-vous les uns les autres. C'est aussi plus amusant de cette façon. De plus, créez une liste de diffusion consacrée à la technologie Java et continuez! (Toutes les entreprises avec lesquelles j'ai travaillé ont ces listes, dont la plupart sont en réanimation en raison de l'inactivité.) Apprenez de vos pairs développeurs - ils sont votre meilleure ressource.

Remarques:

Si vous ou d'autres membres de votre équipe ne comprenez pas le langage de programmation et la plate-forme, comment pouvez-vous espérer créer une application Java d'entreprise réussie? Les programmeurs Java expérimentés adoptent l'EJB et le J2EE comme des canards à l'eau. En revanche, les programmeurs pauvres ou inexpérimentés construiront des applications J2EE de mauvaise qualité.

Description: Je ne comprends pas l'EJB

Phase du projet:

Conception

Phase (s) du projet affectée:

Développement, stabilisation

Caractéristiques du système affectées:

Entretien

Symptômes:

  • EJB qui fonctionnent lorsqu'ils sont appelés pour la première fois mais jamais par la suite (en particulier les beans session sans état qui sont renvoyés dans le pool prêt)
  • EJB non réutilisables
  • Ne pas savoir de quoi le développeur est responsable, par rapport à ce que fournit le conteneur
  • EJB qui ne correspondent pas à la spécification (lancer des threads, charger des bibliothèques natives, tenter d'effectuer des E / S, etc.)

Solution:

Pour améliorer vos connaissances sur les EJB, prenez un week-end et lisez les spécifications EJB (la version 1.1 fait 314 pages). Ensuite, lisez la spécification 2.0 (524 pages!) Pour avoir une idée de ce que la spécification 1.1 n'a pas abordé et où la spécification 2.0 vous mènera. Concentrez-vous sur les parties de la spécification qui vous indiquent, à vous le développeur de l'application, quelles sont les actions en justice dans un EJB. Les sections 18.1 et 18.2 sont de bons points de départ.

Remarques:

Ne regardez pas le monde EJB à travers les yeux de votre fournisseur. Assurez-vous de connaître la différence entre les spécifications qui sous-tendent le modèle EJB et une interprétation particulière de celles-ci. Cela garantira également que vous pouvez transférer vos compétences à d'autres fournisseurs (ou versions) selon vos besoins.

Description: Je ne comprends pas J2EE

Phase du projet:

Conception

Phase (s) du projet affectée:

Développement

Caractéristiques du système affectées:

Maintenance, évolutivité, performances

Symptômes:

  • Le design "Tout est un EJB"
  • Gestion manuelle des transactions au lieu d'utiliser les mécanismes fournis par le conteneur
  • Implémentations de sécurité personnalisées - la plate-forme J2EE possède probablement l'architecture de sécurité la plus complète et la plus intégrée de l'informatique d'entreprise, de la présentation jusqu'au back-end; il est rarement utilisé à toutes ses capacités

Solution:

Découvrez les principaux composants de J2EE et les avantages et les inconvénients de chaque composant. Couvrez chaque service à tour de rôle; la connaissance égale le pouvoir ici.

Remarques:

Seule la connaissance peut résoudre ces problèmes. Les bons développeurs Java font de bons développeurs EJB, qui à leur tour sont idéalement positionnés pour devenir des gourous J2EE. Plus vous possédez de connaissances Java et J2EE, mieux vous serez en conception et en mise en œuvre. Les choses commenceront à se mettre en place pour vous au moment de la conception.

Danger 2: sur-ingénierie (vers EJB ou pas vers EJB)

Phase du projet:

Conception

Phase (s) du projet affectée:

Développement

Caractéristiques du système affectées:

Maintenance, évolutivité, performances

Symptômes:

  • EJB surdimensionnés
  • Les développeurs qui ne peuvent pas expliquer ce que font leurs EJB et les relations entre eux
  • EJB, composants ou services non réutilisables alors qu'ils devraient l'être
  • Les EJB démarrent de nouvelles transactions lorsqu'une transaction existante fera l'affaire
  • Niveaux d'isolement des données trop élevés (dans une tentative de sécurité)

Solution:

La solution pour la sur-ingénierie vient directement de la méthodologie de programmation extrême (XP): concevoir et coder le strict minimum pour répondre aux exigences de la portée, rien de plus. Bien que vous ayez besoin d'être conscient des exigences futures, par exemple les exigences de charge moyenne futures ou le comportement du système aux heures de pointe de chargement, n'essayez pas de deviner à quoi le système devra ressembler à l'avenir. En outre, la plate-forme J2EE définit des caractéristiques telles que l'évolutivité et le basculement en tant que tâches que l'infrastructure serveur doit gérer pour vous.

Avec des systèmes minimaux, composés de petits composants conçus pour faire une chose et bien le faire, le niveau de réutilisation s'améliore, tout comme la stabilité du système. De plus, la maintenabilité de votre système se renforce et les exigences futures peuvent être ajoutées beaucoup plus facilement.

Remarques:

En plus des solutions répertoriées ci-dessus, utilisez des modèles de conception - ils améliorent considérablement la conception de votre système. Le modèle EJB lui-même utilise largement les modèles de conception. Par exemple, le

Home

L'interface de chaque EJB est un exemple de modèle Finder et Factory. L'interface distante d'un EJB agit comme un proxy pour l'implémentation réelle du bean et est essentielle à la capacité du conteneur à intercepter les appels et à fournir des services tels que l'équilibrage de charge transparent. Ignorez la valeur des modèles de conception à vos risques et périls.

Autre danger contre lequel je mets en garde en permanence: utiliser EJB pour le plaisir. Non seulement certaines parties de votre application peuvent être modélisées comme des EJB alors qu'elles ne devraient pas l'être, mais toute votre application peut utiliser des EJB sans gain mesurable. C'est une sur-ingénierie poussée à l'extrême, mais j'ai vu de très bonnes applications de servlet et JavaBean déchirées, repensées et implémentées à l'aide d'EJB sans bonnes raisons techniques.

Danger 3: ne pas séparer la logique de présentation de la logique métier

Phase du projet:

Conception

Phase (s) du projet affectée:

Développement

Caractéristiques du système affectées:

Maintenabilité, extensibilité, performances

Symptômes:

  • JSP volumineux et peu maniables
  • Vous vous retrouvez à modifier des JSP lorsque la logique métier change
  • Une modification des exigences d'affichage vous oblige à modifier et redéployer les EJB et autres composants du backend

Solution:

La plateforme J2EE vous donne la possibilité de séparer la logique de présentation de la navigation et du contrôle, et enfin de la logique métier. C'est ce qu'on appelle l'architecture Model 2 (voir Ressources pour un bon article). Si vous êtes déjà tombé dans ce piège, une forte dose de refactoring est nécessaire. Vous devriez au moins avoir de fines tranches verticales qui sont pour la plupart autonomes (c'est-à-dire que la façon dont je commande un widget est une tranche distincte de la façon dont je change mon nom d'utilisateur ou mon mot de passe). Utilisez cette organisation implicite de votre système pour refactoriser par étapes.

Remarques:

L'utilisation d'une conception cohérente en conjonction avec un framework d'interface utilisateur (taglibs par exemple) vous aidera également à éviter les problèmes de séparation logique sur votre projet. Ne vous embêtez pas à créer un autre framework GUI pour vos propres besoins, il y a trop de bonnes implémentations facilement disponibles. Évaluez chacun à tour de rôle et adoptez le cadre qui correspond le mieux à vos besoins.

Danger 4: ne pas déployer là où vous développez

Phase du projet:

Développement

Phase (s) du projet affectée:

Stabilisation, parallèle, en direct

Caractéristiques du système affectées:

Votre santé mentale

Symptômes:

  • Transitions de plusieurs jours ou d'une semaine vers les systèmes en direct
  • Le risque lié à la mise en service est considérable, avec de nombreuses inconnues et des scénarios d'utilisation majeurs non testés
  • Les données des systèmes en direct ne sont pas les mêmes que les données des configurations de développement ou de stabilisation
  • Incapacité d'exécuter des builds sur des machines de développement
  • Le comportement des applications n'est pas le même dans les environnements de développement, de stabilisation et de production

Solution:

La solution à Danger 4 commence par dupliquer fidèlement l'environnement de production dans votre environnement de développement. Développez exactement la même configuration que celle sur laquelle vous prévoyez de mettre en ligne - ne développez pas sur JDK 1.3 et Red Hat Linux lorsque vous prévoyez de passer en direct sur JDK 1.2.2 et Solaris 7. De plus, ne développez pas sur un serveur d'applications et passez en direct sur un autre. En outre, obtenez un instantané des données de la base de données de production et utilisez-le pour les tests, ne vous fiez pas aux données créées artificiellement. Si les données de production sont sensibles, désensibilisez-les et chargez-les. Des données de production inattendues seront cassées:

  • Règles de validation des données
  • Comportement du système testé
  • Contrats entre les composants du système (EJB-EJB et EJB-database notamment)

Pire encore, chacun de ces éléments entraînera des exceptions, des pointeurs nuls et un comportement que vous n'avez jamais vu auparavant.

Remarques:

Les développeurs quittent fréquemment la sécurité jusqu'à la stabilisation ("Ouais, les écrans fonctionnent, ajoutons maintenant les éléments de validation utilisateur."). Évitez ce piège en consacrant le même temps à la mise en œuvre de la sécurité qu'à la logique métier.