Session Live Coding au Lyon Jug

Un petit retour sur la dernière session du Jug et l'intervention de David Gageot. Je dois dire que j'ai été agréablement surpris car je partais avec un a priori négatif suite à la lecture de l'article de la team  Duchess Lyon élargie. Non pas que l'article n'était pas intéressant, mais plutôt parce que je ne voyais pas la vision de l'informatique de David  Gageot coller avec le monde de l'entreprise.

Au delà du contenu, j'ai particulièrement aimé le format où contrairement à d'autres conférences, le speaker n'a lancé aucun slide. Tout s'est fait en live coding au sein d'IntelliJ, de Chrome et d'une console.

La présentation de David nommée du "Legacy au cloud" était découpée en deux parties

• comment faire du refactoring efficace dans une application legacy ?
• comment déployer rapidement une application dans le cloud ?

Comment faire du refactoring efficace dans une application legacy ? 
Lors de DevoxxFr 2012 David et Jean-Laurent de Morlhon ont animé pendant deux jours une activité "Code story" où le but était de coder une application de A à Z pendant deux jours devant un groupe de personnes. N'étant que deux ils ont organisé un concours pour sélectionner un autre binôme pour les aider. Le concours consistait à résoudre certains problèmes de programmation dont un en particulier, le refactoring d'un code legacy.

Legacy signifie héritage en anglais. Nous utilisons ce terme en informatique pour désigner les systèmes dépassés mais toujours utilisés. Nous n'avons pas la chance de travailler tous les jours sur de nouvelles applications et nous sommes amenés à faire évoluer des anciennes applications. 

David nous a donc présenté ce problème en nous parlant des bons comportements à avoir. Ces remarques sont issues de son expérience mais aussi de son observation du concours Code Story où 18  binômes ont participé

Le premier réflexe à avoir lorsque l'on touche un code existant est de vérifier que ce dernier possède un test unitaire. Si ce n'est pas le cas il faut en rajouter un pour vous assurer que votre intervention ne cassera pas le fonctionnement actuel. Pour faire un test il existe plusieurs méthodes

• partir des spécifications mais ceci est coûteux en temps avant d'avoir une bonne couverture du code par vos tests.Il arrive aussi très souvent que les specs soient décalées par rapport au code car elles ne sont pas toujours mises à jour à chaque évolution
• une autre solution plus efficace est de considérer la classe comme une boite noire. Vous ne vous souciez pas du contenu mais vous écrivez des tests qui se contentent de passer des paramètres à la fonction tester et qui vérifient le résultat. 
• une dernière solution consiste à copier la classe existante que vous ne changerez pas, et votre test compare à chaque fois  les résultats obtenus par votre fonction modifiée, avec ceux obtenus avec la classe originale

Dans tous les cas pour essayer de limiter les risques au minimum, vous devez vous assurer que la couverture du code par les tests s'approchent des 100%.

Pour effectuer les tests David nous a présenté deux outils très intéressants

• fest-assert outil simplifiant l'écriture de vos méthodes assert pour vérifier vos objets renvoyés par la méthode testée 
• infinitest qui permet de lancer un test à chaque enregistrement de votre code, vous permettant d'avoir un rendu immédiat de vos modifications. L'outil est très pratique mais pour qu'il soit efficace, votre test unitaire devra être rapide

Pour le refactoring en soit, David nous a donné une méthode originale. Au lieu de penser dans un premier temps factorisation de code, le but est d'augmenter la duplication du code jusqu'à ce que les améliorations, factorisations deviennent évidentes. 

Un exemple, 

• reprendre les if et n'avoir que des if atomique et ne testant que la valeur positive
• mettre les chaines de carctères lors d'une comparaison en premier
• ...

if(!string1.equals("mavaleur") || int4==5){

   //.......

}

s'écrira 

if("mavaleur".equals(string1)){

}else{

  if(int4==5)

}

Chose étonnante et non visible ici dans mon compte rendu, au fur et à mesure des itérations correctives simples, David a fait ressortir des factorisations qui devenaient évidentes et que l'on n'aurait jamais vu si on était parti tête baissé dans le refactoring.

Infinitest montre aussi tout son intérêt lorsque l'on teste différents cas de refactoring avec son rendu immédiat.

Autre chose assez bluffante chez David Gageot, c'est sa connaissance de tous les raccourcis de son IDE, qui lui permettent tel un pianiste jouant une partition sur son clavier, d'être très efficace.

Comment déployer une application dans le cloud ? 

Dans la deuxième partie de la présentation nous avons eu le droit à une démonstration de la simplicité d'un déploiement d'une application dans le cloud. Il est vrai que sa présentation était simpliste mais son idée de base est à retenir "un bon fournisseur de cloud est un fournisseur chez lequel on rentre facilement et aussi duquel on peut sortir facilement"

Par exemple il n'est pas compliqué de rentrer sur Google App Engine mais une fois déployée votre application ne pourra pas être sortie comme ça   car les services Google ne sont pas exportables sur une autre plate-forme

J'ai bien aimé sa manière de présenter les choses et de faire remarquer qu'il faut penser à faire les choses simplement. Par exemple si vous avez seulement quelques pages web n'utilisez pas un serveur d'application. Pourquoi monter une usine de guerre pour un besoin très simple.

Lors de sa démonstration, David a développé un petit exemple qu'il a exporté sur Heroku. Le principe est simple vous créez un jar construit via Maven et vous spécifiez la classe d'entrée de ce jar. En gros vous n'écrivez qu'un main qui lance un HttpServer. On revient à la base du langage mais la simplicité est souvent oublié lorque l'on a des besoins simples. Les sources sont ensuite publiées sur le repo Git de Heroku qui s'occupe de jouer votre script maven pour mettre à disposition votre application.

Il est vrai que ces solutions simples ne seront pas applicables pour une solution d'entreprise d'envergure mais il est important de choisir la simplicité quand plusieurs solutions se présentent à vous.

En tout cas merci à l'équipe du Lyon Jug et à David Gageot pour cette présentation.