Geek, nouvelles technologies, société et jeux vidéos! | |||||
Aucune information sur l'auteur !
Maven, JUnit, Hibernate, Hudson, GWT, JBoss,... Tant de termes qui font rêver quand on les entend et qui ont un goût de mode en cette période de programmation vouée à l'intégration rapide et à l'extrême développement. C'est donc vers ces technologies que je me suis dirigé lors de ma mutation à Toulouse pour pouvoir mettre quelques lignes de plus sur mon CV et rédiger ce petit article. RésuméUn petit lexique des termes utilisés ci-dessus pour comprendre le contexte Tout s'annonce bien, chaque plugin semble avoir ses propres avantages. Mais... On prend tout et on déploie en local!Je suis donc sur un projet dont on se sert de Maven pour assurer les dépendances entre Hibernate, JUnit,... en passant par des annotations Spring à déployer sur un serveur JBoss avec la partie GWT le tout commandé par Hudson qui envoie un rapport à Sonar...STOOOOOP!! Déjà que je ne connais presque aucune technologie, je dois en apprendre une dizaine en quelques instants avec pour seul appui Google ou mes collègues qui sont occupés sur d'autres modules! De plus il s'agit d'une application Web, par conséquent on doit déployer le projet sur un serveur JBoss afin de le rendre disponible, et pour ne pas se marcher sur les pieds chacun installe un JBoss sur son poste. Heu... attendez : Bilan, plus de 2,5Go de RAM pulvérisés pour une application locale. Sympa pour un simple ordinateur bureautique! De plus il faut déployer, redémarrer le serveur JBoss, redémarrer le plugin de développement GWT, s'assurer que le code a bien été repris et construit, résoudre les problèmes de conflits et de fichiers existants, recommencer tout puisque ça n'a pas été pris en compte,... une bonne heure pour enfin insérer ce "N" oublié dans une chaîne de caractères! Au fait, le serveur JBoss prend 5 minutes à (re)démarrer, beaucoup plus que de déployer sous Android... Hibernate ou la chasse à l'objetBon, il y a deux écoles pour la manipulation de données dans les bases. La première est d'utiliser des requêtes SQL précises pour récupérer uniquement ce dont on a besoin et le stocker dans des variables : Query q = new Query("UPDATE user SET name = '"+newName+"' where id = '"+userId+"'");
q.executeStatement();
La deuxième consiste à créer un objet contenant tous les champs d'une table et l'interfacer avec tous les autres objets en y ajoutant quelques fonctions propriétaires : class User
{
String id;
String name;
String getId()
{
return this.id;
}
String getName()
{
return this.name;
}
void setName(String _name)
{
this.name = _name;
}
}
User user = entityManager.getUser(userId);
user.setName(newName);
entityManager.flush();
Les deux méthodes se valent : la première permet simplement de récupérer les informations nécessaires en maîtrisant les jointures entre les tables, et la deuxième permet de passer outre l'implémentation SQL pour manipuler directement l'objet. Hélas, dans des projets avec des spécifications précises, les objets sont incontournables, trop nombreux et beaucoup trop spécifiques! Je me retrouve donc à mettre des objets dans les objets en cas de jointure (au lieu d'un simple identifiant), certes le moteur d'hibernate gère tout tout seul mais pour récupérer un pauvre champ je dois passer par tout une arborescence d'objets pour juste obtenir le champ qu'il me faut, si ce n'était que ça... il faut que je passe par une montagne de protocoles juste pour avoir l'information :
Voilà tout le beau monde que je dois appeler juste pour récupérer un pauvre champ dans une table, alors qu'une requête SQL aurait pris moins d'une minute! Bon si ce n'était que ça... Les administrateurs de la base de données nous imposent l'appel à une procédure stockée retournant une variable en sortie, à exécuter au début de la session. Avec un connecteur simple ç'aurait été une simple formalité, mais hibernate ne gère pas facilement les sessions, vu qu'il instancie les objets à la volée. J'aurais préféré voir deux objets : un connecteur chez le client et une entité chez le serveur. Cela aurait déjà été mieux au lieu de devoir faire transiter une simple donnée dans un enchevêtrement d'objets! Le modèle GWTJe n'ai rien contre les design patterns (MVC, MVP,...) malgré le fait que je vienne de PHP, un monde où afficher une variable dans une TextBox tient dans une ligne. J'ai aussi l'habitude de travailler avec des modèles MVC surtout depuis que je me suis mis au développement Android, mais là je suis un peu sidéré par tout le code qu'il faut
Déjà quand je vois les deux derniers points, je vois de la répétition! Bon d'un côté c'est pour permettre la vue HTML d'interfacer avec le Java. Jusque ici tout va bien avec le présentateur qui contrôle le modèle et la vue. ET BIM! L'architecte nous impose l'utilisation d'une interface supplémentaire pour lier la vue et le présentateur pour pouvoir faire des tests unitaires plus facilement. Le modèle est lié abstraitement à la vue et nous ne pouvons plus passer par le modèle pour récupérer nos données. Tous mes collègues ont choisi la solution ultime : mettre tous les composants du modèle dans la vue! Et ça marche! LE TOUT SOUS ECLIPSEAh Eclipse, l'environnement de développement qui fait de l'ombre au soleil (à Sun). Cet IDE est surchargé de plugins, de fonctionnalités, de "perspectives" (il s'agit de configurations d'écran) qui le rend très difficile d'utilisation :
Je disais dans un article précédent que l'acharnement est important, mais là on en est à un phénomène de simultanéité comme l'effet papillon ou l'enchaînement d'évènements en fonction de la météo ou des positions des feuilles sur mon bureau. Nous avons un wiki dans l'équipe mais il est progressivement complété par des manipulations phénoménales qui se résument généralement à réinstaller tout le système et donc de perdre une heure en manipulations. Donc pensez d'ores et déjà à bien répartir vos projets dans différents "workspaces" pour mieux les réinstaller. Tout n'est pas noirJUnit est mon module préféré parmi l'avalanche de plugins décrits ci-dessus. Il permet de faire des tests ponctuels sur les différentes fonctionnalités de notre programme, c'est très pratique pour analyser les régressions suite à de grandes modifications de code, une livraison ou un changement de la base de données. Un simple clic droit dans l'interface d'éclipse permet de lancer une série de tests et le débogage de ceux-ci se fait grâce à une trace de la pile d'erreur assez ergonomique. Par contre une fois posés ne les négligez pas! C'est un coup à se retrouver avec une multitude de tests qu'il faudra maintenir, corriger ou pire, feinter... N'oubliez pas que ces tests ne remplacent jamais un test de bout en bout avec l'IHM. Le bilanJe suis arrivé à un point où je dois promettre de vendre mon âme au diable pour qu'un programme puisse compiler, déployer, accéder, débogguer ET marcher correctement et je pense que tous mes collègues sont de mon avis. Encore une fois, chaque technologie prise à part peut être d'une richesse non négligeable dans un projet d'entreprise, mais les mettre toutes ensemble consisterait à construire un bâtiment en utilisant plusieurs ressources et méthodes à la fois. Pour ma part j'ai quand même bien appris l'utilisation de la plupart des technologies et certaines sont intéressantes, notamment les JUnit. Bien sûr il faut derrière un équipement de pointe (multi-écran, 12Go de RAM, un bon architecte,...) et j'aurais moins de pénibilité à faire avancer le projet. Bon, je vous laisse, je dois préparer la chèvre en vue du sacrifice sur le parking tout à l'heure pour que la livraison de ce soir se passe bien... + Sources des images Vous pouvez aussi lire :
|
|||||
|
Votre avis?