BodySplash.fr

Voilà un titre bien obscure. Alors de quoi allons parler aujourd'hui? De la manière la plus simple que je vois actuellement de commencer une application web en java. Il y a quelques semaines effectivement un ami me demandait finalement quoi utiliser pour démarrer un projet de 0 e, avec comme postulat de base que finalement, tout était bien compliqué. Je vais donc décrire ici mes environnements/outils/frameworks favoris qui à mon sens, permettent de s'en sortir dans la grand majorité des cas, et tout en fournissant une base à la fois solide et extensible.

L'environnement

Avant même de commencer à développer, mieux vaut savoir comment nous allons développer. Je pense maintenant qu'il y a une base indispensable à tout projet avant même de penser conception et développement.

Build

Avec quoi construire notre appli? Ca a l'air bête comme question, mais ce n'est en fait pas si simple dans le monde de java, ou tout n'est pas aussi intégré et monolithique que dans le monde .NET.

Par défaut, à peu prêt tout le monde utilisait Ant. Personnellement, je n'en peux plus: xml au kilomètre, dépendances gérées à la main, pas user friendly, bref, une horreur à mes yeux. Si vous lisez de temps en temps ce blog, vous devez vous douter que je vais proposer Maven. Avec maven, il va être possible en 2 lignes de xml d'avoir un projet entièrement compilé, testé, packagé. Les dépendances sont téléchargées depuis un entrepôt central, et il les gère en cascade, donc on ne passe plus des heures à linker ou mettre à jour les libs externes, c'est géré. Si on suit ses conventions, c'est bien simple maven permet de faire oublier une grande partie des tâches techniques de base d'un projet.

Une question qui peut venir et savoir comment organiser son projet dans maven: Multi module ou mono module? l'avantage du multi module est qu'il va garantir une séparation entre les couches, là ou le mono module si on ne fait pas attention peut entraîner un certain mélange. Ceci dit, la complexité du multi module au début ne compense pas ce risque hypothétique, et mieux vaut de toute manière enseigner qu'interdire. Donc, jusqu'à le projet atteigne une complexité trop importante, je préfère la simplicité du mono module tout en faisant attention à ne pas mélanger les couches.

SCM

Même si vous êtes seuls, il vous faut quelque chose pour conserver et versionner votre source, ne serait-ce que par sécurité et pour avoir la possibilité de revenir en arrière. Git a beau être une star montant, je ne le connais pas, et je vais donc me contenter de conseiller subversion: simple, efficace, et non intrusif (pas de lock par défaut sur les fichiers).

IDE

Certains puristes vont certainement dire qu'un éditeur de texte suffit pour développer, mais à mon avis, on est loin d'une productivité optimale. Voilà à mes yeux ce que doit ABSOLUMENT faire un IDE:

• intégrer les test unitaires : pouvoir les lancer facilement, et naviguer rapidement dans le code incriminé par un test rouge,
• refactoring : c'est à mon sens l'outil ultime de productivité et de qualité. Sans aides au refacto il est trop facile, par manque de courage ou de temps, de ne pas faire des changements pour clarifier le code. Pourquoi renommer une classe si ça nous prend 10mn de faire le tour de l'appli pour trouver ceux qui l'utilise? Pourquoi extraire une super classe et centraliser du comportement si c'est un long travail fastidieux de copier/coller? Voilà pourquoi je pense qu'il est juste indispensable qu'un IDE intègre un certain nombre de refactorings assistés
• auto-complétion, coloration, indentation: c'est la base, mais il est bon de le rappeler
• navigation rapide dans le code: il doit être possible d'ouvrir rapidement des types ou des fichiers, mais aussi depuis une classe par exemple d'aller directement dans le code d'un objet qu'elle inclue.

Il y aurait être d'autres choses à ajouter, mais c'est déjà pas mal. Les trois IDE les plus connus du monde java (Eclipse, NetBeans, Intellij Idea) assurent tous ces fonctionnalités en plus d'une intégration à Maven indispensable dans notre cas. Je ne vais pas rentrer dans des débats religieux sur lequel est le mieux, mais personnellement j'utilise Eclipse.

Intégration continue

Je pense que l'intégration continue doit être en place dans le premier jour du projet, il ne faut pas attendre de commencer à avoir des soucis pour la mettre en place. Le minimum est bien sur de compiler l'application et de faire tourner les tests.

Il existe maintenant pas mal de solutions gratuites, mais je dois avouer ma nette préférence pour Hudson, grâce à son esprit "on déploie et ça marche". C'est très simple à mettre en place, il marche très bien avec Maven, et il peut être étendu à souhait avec pas mal de plugins. Que demander de plus?

Les technos

Bien, nous avons la base pour commencer à développer, c'est bien, mais ça ne nous dit pas quels frameworks utiliser pour bâtir notre application web. Au risque de spoiler un petit peu, je vous annonce tout de suite que je ne vais pas conseiller JEE, même en version "simple" en n'utilisant que servlet/jsp.

Restlet

Voici un framework qui mériterait un billet à part entière, mais je vais essayer de faire un résumé. Le but de restlet est de servir de base pour produire et consommer des ressources conformément à l'approche Rest. Ce qui est bien avec ça, c'est que l'on peut commencer très simplement, en faisant une application "à l'ancienne" avec des pages html entièrement générées côté serveur, puis commencer à si on veut à faire plus du RIA, avec GWT, Flex, Dojo, peu importe, les ressources restent les mêmes, on négocie juste une représentation différente.

Comme je le disais, Restlet est très simple à mettre en place, pas besoin de conteneur de Servlet ou autre, il peut démarrer son propre serveur web en une seule ligne de code. Les ressources et la configuration se fait également entièrement dans le code, avec quelques recours très discret aux annotations. Bref, Restlet est une base idéale pour toute application web: il est multi-paradigme, peut grossir en même temps que votre application sans vous forcer une grande complexité dès le début, bref, je suis fan. Ah vous de choisir au début si vous voulez faire une application à l'ancienne, du GWT, du flex etc etc, Restlet supporte tout le monde de toute manière. Suivant ce que vous avez décidé, vous pouvez ensuite par exemple utiliser Freemarker ou Velocity pour générer la représentation html de vos ressource selon une approche MVC bien connue.

Hibernate

Ah voilà un choix plus discutable n'est-ce pas quand on cherche à définir les frameworks les plus simples pour démarrer n'est-ce pas? Le plus simple pourrait-on me dire, serait de directement se connecter à la base, et de faire nos requêtes. Le soucis avec cette approche, c'est que jamais elle ne sera capable de gérer correctement une grande complexité. On se retrouvera nécessairement avec du code mort, de la duplication et une très faible réutilisabilité du code. Ceci dit, il doit y avoir plus simple qu'Hibernate non pour accéder à nos données? Sûrement, mais là je vais devoir avouer que je suis complètement perverti par DDD, et je ne conçois pas de ne pas d'abord penser objet, tester, puis seulement ensuite de faire apparaître la base. Seul un mapper O/R par metadata mapping permet d'utiliser cette approche à 100% , et hibernate est la meilleure solution open source gratuite que je connaisse pour atteindre ce but. Ah mes yeux, et pour une fois, l'effort d'écrire et maintenir tout ce XML me semble complètement être compensé par la valeur: pouvoir écrire un modèle du domaine testable et indépendant de toute considération technique. Le point discutable est sans doute, dans le cadre d'une application juste CRUD, est-ce que ça vaut le coup de sortir l'artillerie lourde? Ma réponse habituelle est que je n'ai jamais connu en 7 ans d'applications qui faisaient simplement du CRUD, donc j'ai le sentiment que ce n'est pas la règle mais le cas particulier. De plus, comment savoir à l'avance que l'application ne fera QUE du CRUD quand on la commence?

Quelques remarques

Il y a bien entendu des critiques à émettre sur le choix des technologies de base, notamment sur la productivité. Il y a peu voir pas du tout de travail prémaché dans ce que j'ai proposé, pas de composants déjà utilisables rapidement, ou de scripts pour générer rapidement les "échafaudages", sans doute parce que je ne suis fan d'aucunes des technologies proposant ces options, car trop de choix me déplaisent dedans (Ruby on Rails et Grails sont très contraignants sur pas mal de points, tant ils font de choix pour nous, Wicket, JSF and co sont orientés composants et modèle par page et ne tirent pas partie à mon avis des avantages du web; Spring MVC est déjà plus sympa, surtout en version 3, mais c'est déjà beaucoup plus lourd que Restlet...)

Si vous lisez régulièrement ce blog, vous devez sans doute savoir que je développe depuis quelques mois maintenant dans un environnement full JEE5. J'ai eu l'opportunité tout d'abord de démarrer un projet de 0, puis de reprendre pas mal d'applications existantes.

Mon premier réflexe en commençant la nouvelle application, à part écrire un test, a été d'appliquer au moins les quelques patterns d'organisation de DDD, à savoir aggregate, entity et value object. J'ai pris tellement l'habitude de structurer mon domaine de cette manière que j'aurai d'ailleurs bien du mal à faire autrement. Bref, comme d'habitude ça a fonctionné et j'ai obtenu un modèle du domaine "taclant" correctement la complexité sans devenir illisible.

J'ai du ensuite reprendre d'anciennes applications également sous JEE donc, et je dois avouer que c'était la première fois que je m'essyais à cet exercice. Oui j'avais déjà travaillé sur des "brown fields", mais ils avaient tous en commun de s'appuyer intensivement sur la base et pas sur du "code". Du coup, ce que j'ai découvert en fait m'a "ouvert" les yeux encore plus sur l'intérêt des patterns décrit dans DDD. Car finalement, ce que j'ai eu à reprendre est globalement du code qui essayait d'utiliser les concepts EJB3, mais sans auncune structuration. Donc on se retrouve avec des DAO dans tous les sens, même pour récupérer des entités dépendantes d'une racine; on trouve carrément des références vers des ID plutôt que vers les entités réelles, des références croisées dans tous les sens, bref, je me suis retrouvé face à ce que tout que les concepts d'aggregate/entity/value objet essayent d'empêcher, tous ces problèmes qui font croire à pas mal de gens que l'objet, c'est imbitable.

Bilan de cette histoire:

• et d'une, il y a toujours des choses à prendre dans DDD,
• de deux, avant d'entrer dans des systèmes aussi complexes que peuvent être les différents serveurs JEE, et se vanter de faire des supers architectures , il faudrait se concentrer sur qui compte réellement : le code. Je ne veux pas faire une généralité de cette règle, mais je ne compte pas le nombre de tutoriaux/messages de forum/newsgroup etc etc ou j'ai pu constater ce phénomène de "branlette sur l'architecture" alors que le code montré en exemple était tout simplement dégueulasse.

L'architecture n'est pas un paliatif à du code de piètre qualité.

La question est classique, mais le débat est revenu plusieurs fois ces dernières semaines ou moi au d'autres collègues avons du faire passer quelques entretiens. C'est une question bien entendu très ouverte, donc je vous laisse vous défouler dans les commentaires

Très personnellement, je ne pense pas que l'on puisse juger quelqu'un à la somme de ses connaissances. Mieux vaut une tête bien faite qu'une tête bien pleine comme disait l'autre. Donc, contrairement à ce qu'on pourrait penser, même si par curiosité je vais demander, je ne vais pas attendre de quelqu'un qu'il sache tout de l'agilité, des principes SOLID, de DDD etc. etc. Je vais sans doute me moquer encore plus des connaissances encore plus techniques comme les détails d'mplémentation de tomcat ou ses différents connecteurs. Mais alors qu'est-ce qui importe? Ce qui importe, c'est que tous les éléments que je viens de citer peuvent s'apprendre. C'est donc mon premier grand point: savoir et vouloir apprendre.

Ensuite, à mon sens ce qui fait le plus la qualité d'un développeur c'est la qualité de son code. Oh la belle phrase. Qu'est-ce que ça veut dire? Essentiellement pour moi qu'il est maintenable. Comment rend on le code maintenable? Essentiellement en lui donnant du sens. Ca a peut être l'air tout con comme ça, mais j'ai très personnellement le sentiment qu'en France le code est très mal vue, et que globalement la grande majorité des formations que nous recevons sont à base de "le code c'est le mal, mais plus tard vous serez chef de projet et vous en ferez plus". A partir de là pourquoi dépenser des efforts dans quelque chose qui est apparemment par définition imbitable et chiant?

Mais je digresse, pour résumer en deux principes, voilà finalement ce que je recherche:

• amélioration continue
• donner du sens au code

Ce qui me plaît dans ces deux principes, c'est qu'ils permettent de juger tant les débutants que les vieux routiers. Une fois que ces deux qualités sont identifiées, il suffit d'estimer "l'avancement" sur le chemin. Par exemple, donner du sens au code commence par bien nommer ses variables, et continue (bien) plus tard par DDD.

Voilà presque un an que nous travaillons sur "Le Projet", mais je n'en ai pas parlé depuis avril. Je vais corriger le tir en tentant un bilan de l'année.