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...)
Ceci dit, je vous le fait passer également car j'aime bien montrer que je ne parlais pas dans le vent, et que le phénomène que j'avais anticipé existe réellement.
Fowler est plus dans le consensus que moi, et ne démonte pas Scrum. Mais personnellement, je maintiens ce que je disais: pourquoi choisir Scrum quand XP est complet et n'induit pas le risque d'oublier ou le planning ou l'ingénierie?
