JUG Summer Camp 2012 : Du legacy au cloud en moins d’une heure

Voir une session de Live Coding par David Gageot est toujours un pur bonheur ! On y découvre en quelques minutes un ensemble complet de bonnes pratiques, de trucs et astuces et de retour d'expérience pour être de plus en plus efficace.

Le thème que David a retenu est "comment reprendre un code qui vous est imposé avec ses spécifications pour le faire évoluer vers le cloud ?".

Le code Legacy

Il part de son code d'origine et de ses spécifications et nous montre comment s'y prendre.

La première démarche est d'être conscient qu'on n'y connait pas grand chose au domaine fonctionnel qu'on nous demande de reprendre. La première chose à faire est donc d'écrire des tests et de les faire tourner sur le code "Legacy". Ils seront par la suite l'élément principal pour s'assurer de notre non régression.

Les tests

Pour écrire les tests, deux méthodes :

  • Prendre les spécifications, les comprendre et coder des jeux de test
  • Exécuter différents bout de codes, regarder le résultat généré par le code Legacy et simplement indiquer dans le cas de test que notre résultat doit être celui-là.

Cette dernière méthode a l'intérêt de ne pas obliger à comprendre le fonctionnel pour mettre en place des tests.

Afin de s'assurer en permanence que notre code ne régresse pas, David utilise le plugin Infinitest qui s'assure à chaque sauvegarde de fichier que les tests passent toujours. Ainsi, le développeur sait immédiatement que sa modification a introduit ou non une régression. Inutile de coder d'avantage ; il faut fixer le code immédiatement !

Le refactoring

David a donc créé les tests nécessaires et peu s'attaquer au refactoring de code. En effet, le code Legacy dont il hérite est assez mal fichu, mal structuré et peu lisible. Il a toutefois une contrainte qui lui est donnée par son client : il n'a pas le droit de toucher la classe Item.

Il va alors enchaîner des déplacements de code, de l'indentation, de la mise en commun de code, extraction de méthodes dans des classes utilitaires, ... (ce qui est assez peu descriptible ici) pour au final arriver à un code beaucoup plus léger et propre. Pendant sa démo, il va régulièrement casser les tests et réparer de manière continue.

Un service REST/JSON

L'étape refactoring étant passée, il peut s'attaquer à la mise sur le cloud de son code.

Pour cela, il va utiliser les fonctionnalités de JEE6 et fabriquer une simple fonction main() et embarquer un serveur Web capable de lui fournir des réponses REST/JSON. Au passage, comme son cas est simple, il ne se complique pas la vie pour générer du JSON à l'aide de librairies (type Jackson) mais fabrique directement des réponses "String".

David lance son application sur son poste et rend sur http://localhost/ et affiche son premier document JSON. Il lance ensuite http://localhost/update pour solliciter en REST la méthode updateQuality() puis ouvre à nouveau le document précédent pour constater que ses items ont changé.

Le passage aux nuages

David utilise Heroku pour la suite de sa démonstration. Il a choisit ce service car Heroku permet de lancer dans le Cloud des applications Java (main()). Les autres fournisseurs exigent en général un livrable type WAR pour en permettre le déploiement. Son application tournera donc à l'adresse : http://fast-fortress-9739.herokuapp.com/. La mise à jour se fait par un appel à http://fast-fortress-9739.herokuapp.com/update

David a également développé une petite application web, en réalité, une page web hébergée sur github : https://github.com/dgageot/jug-summer-camp-web/blob/gh-pages/index.html

Cette page fait appel au service REST/Json, affiche le contenu rendu par le service REST et permet de solliciter l'API update.

Quelques trucs et astuces

David nous livre finalement quelques conseils supplémentaires :

  • Héberger votre contenu web sur Github en utilisant Github Pages. Cela vous permet facilement de faire tourner vos interfaces graphiques.
  • Utiliser le CDN (Content Delivery Network) pour récupérer les ressources statiques communes (JQuery, CSS Twitter bootstrap, Mustache, ...) Les sites CDN sont prévus pour fournir des ressources statiques le plus rapidement possible avec une meilleure qualité de service que Github Pages.
  • Utiliser Heroku pour le reste (service REST). L'idée étant de minimiser l'usage d'Heroku pour éviter d'être facturé inutilement pour les éléments statiques pouvant être fournis par ailleurs.

En 40 minutes, David nous a montré comment appliquer un certain nombre de bonnes pratiques pour prendre une application inconnue et la transformer en application dans le Cloud. Pari plus que réussi avec une vraie démonstration en Live. Tout y était, maîtrise de son environnement IntelliJ IDEA, raccourcis efficaces, humour, talent... Bravo !