Projets Java EE - problèmes principaux rencontrés dans des projets précédents

Les erreurs les plus graves et les plus souvent rencontrées dans les projets. Il y a eu aussi évidemment de bonnes choses mais je ne parle ici que des problèmes pour que les erreurs ne soient pas répétées dans les prochains développements d'applications.

IMPORTANT : comment demander de l'aide

Tout d'abord une grosse erreur que font souvent les étudiants est de demander de l'aide sans donner les informations indispensables pour les aider et résoudre le problème.

Si vous demandez de l'aide, à un enseignant, un camarade ou sur Internet, il faut bannir les formules du type "ça ne marche pas", "ça ne s'affiche pas", non accompagnées d'un message d'erreur (le plus souvent au moins le message d'erreur des logs du serveur affichés en bas dans NetBeans) et d'une description précise de la situation et des étapes que vous avez suivies pour arriver au problème.

Les personnes qui souhaitent vous aider auront du mal à le faire si vous ne leur facilitez pas la vie. Elles vont devoir deviner où vous avez pu faire une erreur et seront obligées de vous reposer des questions (la plupart ne le feront pas et elles ne vous aideront pas).

• Tout d'abord une remarque : malgré mes avertissements plusieurs groupes ont commencé à réfléchir au projet et à coder trop tardivement. Les sujets des projets demandent une réflexion, des apprentissages et des tests préalables pour les fonctionnalités à risque. Commencer un projet tardivement c'est bien souvent aller à la catastrophe. Le travail en groupe a ses avantages (échanges d'idées, moins de fonctionnalités à implémenter pour chacun) mais comporte aussi ses difficultés (en particulier l'intégration des fonctionnalités) ; ne les sous-estimez pas.
• La moindre des choses est de faire le ménage dans votre application avant de la livrer : pas d'erreur signalée par l'IDE surtout si elle empêche la compilation, indentez le code.
• Une application professionnelle est une application documentée. Très souvent les projets ont une documentation insuffisante et en particulier pas de commentaires javadoc (grave erreur), même pas un simple commentaire sur chaque classe (c'est le minimum) ou pour décrire les méthodes qui ne sont pas évidentes à comprendre. Inutile de mettre des commentaires pour les parties évidentes du code ; dans le doute (est-ce évident ou pas ?), ajouter un commentaire. Les commentaires devraient être écrits en même temps que le code pour ne pas oublier de les écrire et pour vous aider quand ce code est utilisé dans la suite du développement. Pour vous motiver, sachez que la documentation de l'application (javadoc et fichiers de documentation) compte pour environ 5 points (sur 20).
• Dans le fichier readme (ou le guide pour l’utilisateur) vous devez expliquer comment lancer votre application. Les explications doivent être assez détaillées pour pouvoir s’adresser à une personne qui n’est pas experte dans le domaine.
• Un guide de programmation n’est pas la donnée que quelques lignes de code sans aucune explication de plus que dans l’application.
• Une erreur fréquente : mettre dans le guide de programmation une énumération des classes avec, pour chaque classe (ou quelques unes), le commentaire qui aurait dû être un commentaire javadoc écrit dans la classe. Normalement il suffit de lire la javadoc pour avoir ces informations. Elles peuvent être évidemment répétées dans le guide de programmation mais elles ne sont pas ni suffisantes ni nécessaires.
• Un guide de l’utilisateur doit contenir des captures d’écran mais le plus souvent ça ne suffit pas et il faut ajouter des explications. Mettez-vous à la place du correcteur qui ne connait pas votre application. Aidez-le à la tester.
• Vous utiliserez sans doute une base de données ; n'oubliez pas d'écrire dans le guide de l'utilisateur son nom et le nom du user et son mot de passe (peut-être aussi dans le readme). S'il faut entrer un nom de login, donnez les noms et les mots de passe des utilisateurs que vous avez créés dans l'initialisation de l'application. Le correcteur ne doit pas avoir à lire votre code pour connaitre ces informations.
• N’oubliez pas que le choix des noms des paquetages, classes, méthodes et variables est très important pour la compréhension du code. Utilisez les noms du domaine si possible (les noms utilisés par les personnes qui connaissent le domaine à informatiser).
• Limitez la portée des backing beans. Une portée session est à réserver à de rares beans pour conserver des informations pendant toute la session. Sinon la mémoire utilisée sur le serveur sera trop importante et il y aura des problèmes si l’utilisateur ouvre plusieurs onglets dans le navigateur pour l’application. Utiliser plutôt les portées requête, vue, conversation ou flot (choisissez toujours la portée la plus restreinte possible). La portée requête sert pour les cas simples où le traitement utilise directement les données saisies par l’utilisateur (voir TP 2 sur PRG). Dès que le traitement est plus complexe, il est souvent nécessaire d’élargir la portée à vue, flot (ou conversation). La portée vue sert pour le cas où une seule page JSF est utilisée ; sinon, il faut passer à la portée flot (ou conversation).
• S’il est demandé un fichier bugs.pdf ça n’est pas pour écrire que tous les bugs ont été corrigés alors que de nombreuses parties du projet ne fonctionnent pas. Un bug non signalé est plus sévèrement pris en compte dans la note.
• Une application est écrite pour résoudre un problème, pour aider des utilisateurs. Écrire une application qui n’a pas d’utilité ne sert à rien (par définition:-)). Par exemple, écrire une application qui gère des QCM qui ont exactement 4 questions, avec exactement 4 réponses possibles par question, dont une seule réponse est valable (surtout si la bonne réponse est toujours affichée en premier:-)), ne sert à rien car la plupart des QCM n’ont pas cette contrainte. Ça sera simplement plus facile à écrire, mais il faudra récrire une bonne partie du code si on veut se débarrasser de ces contraintes pour rendre l’application vraiment utile.
• Si vous utilisez des requêtes POST sans appliquer le modèle PRG expliqué en cours (et dans un TP), les utilisateurs de vos applications Web seront confrontés au problème de la double soumission des formulaires (très gênant), l’URL de la page ne reflètera pas la page affichée et il sera impossible à l’utilisateur de garder l’adresse d’une page dans ses marque-page.
• Attention, Primefaces utilise JQuery en interne. Plusieurs projets étaient très instables et comportaient des pages très longues à charger à cause d'une utilisation explicite de JQuery dans ces pages ou dans les templates utilisés par ces pages. Si vous utilisez vos propres fichiers JQuery vous risquez d'avoir des problèmes de compatibilité avec la version de JQuery utilisée par PrimeFaces. Et tout ça le plus souvent pour avoir juste des menus un peu plus dynamiques... Est-ce que ça vaut le coup ? Il vaut mieux vous attacher à implémenter les fonctionnalités demandées et ajouter les parties "fun" ensuite, si tout marche bien par ailleurs.
• Problème rencontré pour un seul groupe, mais ça peut servir aux autres groupes. Quand un client vous demande une application qui tourne dans un certain environnement, avec une certaine base de données, ne lui écrivez pas une application qui tourne dans un autre environnement, avec une autre base de données ! Le minimum à faire si vous pensez que l’environnement ne convient pas est d’en parler au client (ici c'est l'enseignant) et de suivre ensuite son avis.
• Un des groupes a eu la note 0 parce que le projet était une copie d'un autre projet, à peine retouché. Je rappelle qu'on peut demander de l'aide à ses camarades sous la forme d'explications de notions ou pour demander des références à travailler sur le Web ou dans les livres mais qu'il est absolument interdit de demander du code déjà écrit (celui qui reçoit ce code sera pénalisé mais aussi celui qui le fournit).
• L'ergonomie est importante. L'utilisateur doit pouvoir utiliser l'application sans trop se poser de question et il ne devrait avoir besoin de consulter le guide utilisateur que rarement.
• Les messages d'erreur sont indispensables pour informer l'utilisateur des éventuels problèmes. N'oubliez pas de tester un mode "production" pour voir si ces messages sont toujours affichés.
• Les messages de succès sont tout aussi indispensables ! Rien de plus énervant que de lancer une opération et de ne pas savoir si tout s'est bien passé.
• @DataSourceDefinition ne doit apparaître que dans une classe du projet (s'il n'y a qu'une seule source de données) et pas dans plusieurs classes (comme, par exemple, sur tous les EJB qui utilisent la source de données).
• Erreur de débutant mais que j'ai déjà rencontrée : ne confondez pas les paradigmes objet et relationnel ! Les associations entre objets se font avec des références d'objets et pas avec des ids d'objets comme on le fait en relationnel (clés étrangères qui utilisent un id). Revoyez comment se font les associations dans le TP 5 ("associations avec JPA") si vous ne comprenez pas. Si vous vous trompez, votre modèle objet est totalement faux et votre application sera construite sur des bases erronées.
• Mauvaise sécurité (pour les projets qui ont plusieurs types d'utilisateur et pour lesquels les utilisateurs doivent taper un login et un mot de passe ; pas pour les projets 2016 et 2017 qui doivent utiliser une version simplifiée de l'authentification) :
  • On ne doit jamais écrire les mots de passe en clair dans la base de données (si vous lisez l’actualité informatique vous comprendrez pourquoi !).
  • Il est souvent facile d’accéder aux fonctionnalités interdites en tapant tout simplement le bon URL ! Java EE a une façon standard pour authentifier les utilisateurs et pour protéger les parties interdites aux utilisateurs ; il faut l’utiliser et ne pas inventer sa propre façon (trop compliqué et souvent contournable).