Projets Java EE - problèmes principaux

Les erreurs les plus graves et les plus souvent rencontrées dans les projets (j'ai aussi inclus des remarques sur des projets écrits par d'autres promotions d'étudiants, qui pourraient être utiles à tous). Il y a eu aussi 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.

Tout d'abord une remarque : malgré mes avertissements plusieurs groupes ont commencé à réfléchir 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) mais comporte aussi ses difficultés (en particulier l'intégration des fonctionnalités) ; ne les sous-estimez pas.
Des projets n'étaient que des brouillons de projet. De très nombreuses fonctionnalités ne marchaient pas. Quand la date pour rendre un projet est éloignée de plusieurs semaines, on n'attend pas le dernier moment pour réfléchir au projet et pour coder les parties "à risque" (celles pour lesquelles on ne sait pas trop comment faire). Par rapport à d'autres promotions de même niveau (master 2), j'ai remarqué un manque flagrant d'expérience de la programmation pour certains étudiants de l'UFE.
Documentation souvent bâclée et en particulier pas de commentaires javadoc (grave erreur), même pas un simple commentaire pour dire ce que fait la classe et pour décrire les méthodes qui ne sont pas évidentes à comprendre.
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 ça n’est pas la donnée que quelques lignes de code sans aucune explication de plus que dans l’application.
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.
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.
Mauvaise sécurité :
- 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).
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 ou conversation (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. Dès que le traitement est plus complexe, il est nécessaire d’élargir la portée à vue ou conversation. Vue sert pour le cas où une seule page JSF est utilisée ; sinon, il faut passer à la portée 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 charge dans la note.
Une application est écrite pour résoudre un problème, pour aider des utilisateurs. Ecrire 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 n’utilisez pas 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 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é.