Ce mardi se tenait le second Barcamp organisé par Octo.
J'en profite pour remercier encore une fois Luc Bizeul pour son organisation impeccable, et pour m'avoir prévenu de l'événement.

Comme la fois précédente, 6 tables-rondes (3 salles x 2 séances) ont été organisées autour de sujets proposés par les participants eux-mêmes. Au final, les thèmes sélectionnés étaient :

• Le web sémantique : Rest, RDF, OWL
• Génération de code
• Devoxx : compte-rendus et annonces
• Intégration continue : Maven, Selenium, Gant, Gradle
• ESB : Spring Intégration vs Mule
• Groovy et Grails

Après les deux séances, un buffet était offert, permettant de prolonger les discussions en plus petits groupes. Sur la grosse cinquantaine de participants, on pouvait retrouver quelques habitués comme Florent Ramière de chez Jaxio, Nicolas Martignole du Touilleur-Express (voir également son compte-rendu), Julien Dubois de SpringSource, et quelques collègues de Zenika.

(Entre parenthèses, nous avons également eu droit à quelques goodies, dont la fameuse "boîte à meuh" emblématique d'Octo : en théorie, on s'en sert de manière chirurgicale pour couper court à tout dérapage lors d'une réunion, mais je vous laisse imaginer le potentiel cacophonique d'un tel engin laissé entre les mains d'une pleine salle de développeurs facétieux. A noter que la notice accompagnant la boîte, présentée comme une notice médicale, vaut également son pesant de cacahuètes...)

Mais revenons aux sujets auxquels j'ai assisté : Génération de code et ESB.

Génération de code

Cette séance fut intéressante car les cinq personnes autour de la table avaient des expériences différentes sur la génération de code :

• Florent Ramière de chez Jaxio, éditeur d'un générateur de pile technologique (Spring/Hibernate/Struts/...)
• Eric LeMerdy et Eric Lefèvre de chez Valtech, ayant pratiqué l'approche MDA
• Xavier Maysonnave de chez Soyatec, éditeur de produits opensource basés sur Eclipse (eFace, eUML2, eBPMN)
• Et moi-même, consultant Java

Nous nous sommes d'abord demandé quels étaient les use-cases pour la génération de code.
Pour Florent, la génération d'artefacts techniques simplifie et accélère le développement initial d'une application, mais permet surtout d'abaisser la barrière technologique pour les développeurs juniors. Par exemple, on pourrait ainsi reconvertir facilement un ex-Coboliste aux architectures N tiers Java. Idéalement, toute la couche technique boilerplate pourraît être générée automatiquement^[1]. Eric a illustré cette idée par l'exemple d'un client dont la cellule d'architecture éditait un framework censé, à terme, remplacer une partie de leurs développeurs "standards"...
Pour ma part, je pense que la micro-génération de code permet également à un développeur d'améliorer sa productivité en automatisant certaines tâches répétitives et/ou peu valorisantes (ex: générer le struts-config.xml) et de capitaliser sur des bonnes pratiques ou des points techniques particuliers (ex: écrire correctement un singleton).

De toute façon, selon Xavier, l'intérêt de la génération de code s'érode à mesure que l'on s'éloigne des couches basses : il est facile de générer des DAO, mais l'interface utilisateur restera toujours problématique; les outils permettant de le faire ne donnent que de piètres résultats en termes de qualité et de performance. De plus, la prise en compte par un générateur des mille et une spécificités graphiques demandées par les clients sera toujours nettement plus coûteuse et moins flexible que l'intervention manuelle d'un développeur compétent.

Mais les outils évoluent rapidement. Certains permettent désormais de re-générer du code tout en conservant les modifications manuelles effectuées entretemps. Florent estime que les experts préfèrent tout de même fusionner leurs documents à la main, afin de s'assurer qu'aucune modification n'est perdue dans le processus. Certains outils utilisent des balises ou des annotations pour distinguer le code généré du code "manuel" ; Rational Software Architect s'en sort plutôt bien grâce à cette technique, à condition de suivre quelques règles simples (notamment, bien penser à supprimer l'annotation @generated). Le produit de chez Jaxio, Célério, propose une approche alternative basée sur les métadonnées de CVS et sur un principe intéressant d'extension des classes générées.

Quant à écrire soi-même un générateur, Florent et Eric sont d'accord pour respecter la règle du 80/20 : il est inutile de chercher à gérer tous les cas possibles du premier coup. Le générateur doit au contraire rester simple et facilement adaptable, particulièrement dans le cadre des méthodologies agiles où les spécifications peuvent changer à chaque itération. Dans cette optique, les technologies utilisées seraient plutôt EMF et Jet pour Xavier, et Velocity pour Florent, Eric et moi.

En conclusion, cette séance fut très instructive. Le faible nombre de participants a facilité les échanges, et la variété de leurs profils apporté un éclairage intéressant sur la problématique de la génération de code dans son ensemble.

Photos

Le compte-rendu de la séance sur les ESB fera l'objet d'un prochain billet.