BodySplash.fr

Comme beaucoup de monde, j'avais une certaine aversion pour JavaScript. Ces derniers mois m'ont permis de remettre un peu en perspective pas mal de mes anciennes croyances. Vous allez sans doute me demandez comment la magie à-t-elle opérer (ou pas)? Et bien en fait assez simplement à partir du moment qu'on décide de lui donner sa chance, et d'arrêter de se contenter de hacker quelques bouts copiés/collés à droite à gauche. Voici en tout cas pour moi les grands points qui m'ont permis non pas de devenir un expert, mais de pouvoir m'en servir sans hurler à la mort :

• Le plus gros manque finalement au départ de javascript, c'est un framework de base livré avec l'engin. Sans ça, on a l'impression de réinventer 100 fois la roue, et de perdre pas mal de temps à faire la même chose. Le premier conseil est donc d'utiliser une des fantastiques librairies qui vivent dans le coin. Leur philosophie peut varier, donc méfiance, mais je préfère personnellement m'appuyer sur jQuery, car je le qualifierai bien de plus simple qui fonctionne. Il est malgré tout à la fois très puissant et extensible à souhait. Je dois avouer que du coup je n'ai pas trop essayé la concurrence qui en comparaison semblait bien plus complexe.

• Il faut se rendre compte que JavaScript est un vrai langage, avec son propre paradigme, et qu'il ne sert donc à rien de tenter de ramener toutes ses habitudes de nos langages favoris (java, c#, python ruby, choisissez celui qui vous fait plaisir). Comprendre ce qui se passe et les quelques concepts de base qui animent le langage fait déjà beaucoup pour commencer à l'apprécier. C'est pour cette raison par exemple que encore une fois je préfére jQuery à prototype, car il n'essaye pas d'ajouter un support "classique" de l'orienté objet au langage, il lui demande juste d'être lui même, naturellement. J'aimerais bien vous conseiller un bon tutorial sur le sujet, mais hélas j'ai appris tout ça dans deux bouquins.

• Le conseil bateau maintenant, il faut s'abstraire le plus possible du navigateur en utilisant une bonne librairie : ça recoupe en grande partie le premier point, mais c'est surement le soucis qui retient beaucoup de monde à apprendre Javascript. jQuery fait un boulot fantastique pour faire oublier là plupart des soucis de compatibilité, même s'il reste bien entendu quelques problèmes à droite à gauche.

• Enfin, mais sans doute le point plus important, les bonnes pratiques de programmation ne sont pas à jeter tout simplement car on se trouve côté navigateur. Il n'y a pas de secret, le seul moyen de vraiment tirer partie de javascript est d'appliquer les bonnes pratiques, DRY et TDD en tête de liste. Il existe quelques frameworks de tests unitaires en javascript, même si rien n'est parfait bien entendu pour le moment dans ce domaine, surtout lorsqu'il s'agit de les faire tourner automatiquement pendant l'intégration. TDD fonctionne bien en javascript encore une fois du moment qu'on essaye de pas de tordre le langage dans un orienté objet "classique". Pour reparler, encore, de jQuery, développer ses fonctionnalités sous la forme de plugin pour ce dernier les rend incroyablement plus testable et réutilisable.

Ma conclusion finalement serait qu'il y a encore quelques mois, je lorgnais beaucoup du côté GWT pour les mauvaises raisons : la peur de javascript. Paradoxalement, avoir adopté ces derniers mois Restlet, freemarker et jQuery a beaucoup simplifié le développement que les quelques essais avortés avec GWT. Le plaisir des choses simples il faut croire Ces framework sont solubles dans une approche ROA là ou GWT l'est beaucoup moins.

Pour aller plus loin, javascript commence même à envahir la programmation côté serveur grâce aux deux initiatives CommonJs et Node.js. Il y a un bon article sur le sujet dans le pragpub de ce mois-ci

Que d'acronymes dans ce titre. Hier soir, je suis donc allé pour la première fois à une réunion du JUG Bordelais car et d'une, je ne connaissais pas avant, et de deux, le sujet était TDD, et si vous me suivez un peu vous devez savoir que j'y accorde une certaine importance.

Pour mettre les choses au clair, le TDD est pour moi un point critique pour l'avenir de notre profession (oui carrément). Comme aime à le répéter l'oncle Bob, nous devons devenir des professionnels, et cela passe essentiellement par écrire du code propre. Hors comment écrire du code propre? Et bien pour le moment je n'ai pas trouvé mieux, et apparemment je ne suis pas le seul, que d'écrire les tests avant de coder.

Donc voilà le cadre posé, qui va me permettre maintenant de décrire ma déception. C'était un retour d'expérience sur un forfait mené normalement par les tests. Déjà, premier signe d'alarme, l'équipe s'est mise à tdd contrainte et forcée, car c'était une exigence du client. Deuxième point noir, personne dans l'équipe ne connaissait l'approche, du coup bien entendu, ils ont eut d'énormes difficultés à s'y mettre sans quelqu'un d'expérimenté pour montrer l'approche. Suite à cette présentation du contexte, on enchaine donc par une présentation un poil trop succincte de ce qu'est TDD. Ouf on a eu droit au moins un cycle test, code, refactor, mais le refactoring est à mon avis trop passé à la trappe. Disons plutôt qu'il était considéré comme acquis pour le public ou l'orateur, ce qui à mon avis n'était pas du tout le cas. Le plus gros défaut finalement et que cette introduction n'a montré tdd que comme une pratique de qualité, et pas d'architecture. Pire encore, cette présentation a été faite dans l'esprit que la qualité s'oppose à la productivité, ce qui est une des pires idées reçues de notre métier. La productivité passe par la qualité, inévitablement; j'y reviendrai plus loin.

Ensuite, s'en est suivi une partie bien trop longue à mon avis sur les problèmes que l'équipe avait rencontrés, et leurs solutions. Je pense que pour quelqu'un ne connaissant pas le sujet, toute cette partie a eu plutôt tendance à convaincre que tester, c'est long, cher et compliqué.

On finit ensuite par une métrique qui m'a obligée à réagir, encore une fois sur la productivité, à base de "regardez, l'application fait 3000 lignes, mais on a du faire 12000 de lignes de tests . Bouh la productivité de merde". Ok, alors premier point, je crois que l'on s'est bien rendu compte que productivité et nombre de ligne de code n'avait juste rien à voir. Piloter son code par les tests permet d'écrire du code plus concis et mieux structurer, et par la même moins gros qu'un code écrit sans les tests. Donc ces fameuses ligne de code que prennent les tests qui sont soit disant le mal absolu (on est pas payé à tester voyons), combien de lignes de code de production ont-elle économisées? Et à votre avis, entre un code qui fait juste ce qui est attendu, et un code qui en fait trop car il est parti dans les peut-être, lequel a le plus de chance de contenir des bugs? De plus, si on suit le cycle tdd: code de test qui suffit à être au rouge, code minimum pour faire passer, refacto; combien de temps passe-t-on dans le debugger? Oui ces grandes sessions de debugging, où l'environnement met plusieurs minutes à démarrer, où on pose des points d'arrêt à l'aveugle, où on rate son passage donc on doit recommencer; oui elles disparaissent pratiquement intégralement quand on mène correctement le développement par les tests. Pas un mot là dessus hier soir (enfin si, là j'ai pas pu m'empêcher de dire quelque chose). Autre gain de temps par tdd: on reste concentré. Plus de temps perdu car on papillonne sur trop de tâches en même temps: on reste concentré sur le test en cours, ce qui peut le faire passer au rouge ou au vert, et rien d'autre. Le fameux "turnaround" est ainsi réduit. Bien entendu, le gain final évident est qu'il est excessivement plus facile de découvrir et corriger les bugs quand on a produit l'application avec les tests qu'autrement.

Ah ce stade là, je tiens à féliciter la brillante intervention d'un des auditeurs, qui a tout de même sorti que comme les bugs, c'est de la maintenance, et que nous notre travail, c'est le développement, alors on en a rien à foutre de produire une application de qualité. Dixit le bonhomme, le client ne testant pas tout, il va accepter la livraison, nous donner le chèque, et ça nous suffit. Cette attitude à un nom: c'est de l'escroquerie, comme vendre une voiture d'occasion avec des freins prêts à céder. On a fait la vente, mais on a des chances de tuer le client. Cette vision est à mes yeux incroyablement limitée et pourrait presque s'apparenter à l'économie de la Camorra: un profit à très court terme sans considération pour les externalités négatives. Non seulement, le client ne reviendra sans doute pas, (je le sais, j'en récupère des déçus en ce moment), mais en plus, on donne une image de garagiste aux informaticiens. Vous avez déjà eu ce sentiment, en allant faire réparer votre voiture que vous allez vous faire truander? Et bien c'est exactement ce qu'est en train de devenir notre profession avec des attitudes pareils. Je crois que Michael a d'ailleurs bien répondu hier soir à cette remarque Je pourrai ajouter que je ne crois pas de toute manière en cette opposition développement/maintenance, et que la maintenant débute dès le premier commit, mais ce serait un peu hors sujet.

Une question également est passée à laquelle je n'ai pas eu le temps de répondre, c'était l'éternel "le client doit être mature pour accepter les tests". Ah ça je répond, que nous n'avons pas à vendre les tests. Nous n'avons pas à vendre au client que nous allons utiliser de l'intégration continue ou du refactoring. Nous n'avons pas à lui demander s'il préfère qu'on laisse un swicth à la place d'un polymorphisme, s'il préfère qu'on utilise eclipse ou netbeans Ce que je veux dire, ce que nous n'avons pas à lui vendre notre manière de travailler pour qui l'accepte. Il faut arrêter un peu de se plaindre tout le temps car on a pas l'autorisation de faire les choses comme on le voudrait. En tant que professionnels, nous sommes seuls en charge de notre manière de travailler. Nous sommes grands et responsables, et devons assumer pleinement le fait que nous avons un métier. La manière dont on l'accomplit techniquement regarde peu le client du moment que nous maximisons son investissement.

Pour conclure, j'ai tendance à penser que toute initiative pour faire découvrir TDD est bonne à prendre, mais la présentation d'hier soir animée par quelqu'un de très peu expérimenté dans l'approche, et qui apparemment du coup n'était pas du tout convaincu, à fait plus de mal que de bien à mon avis. J'ai conscience bien entendu que je ne prend pas de gants dans ce billet, et si je choque certaines personnes je m'en excuse, mais les commentaires sont ouverts, et puis si des gens du JUG me lisent, pourquoi ne pas organiser un contre débat?

P.S: toutes ces questions sont finalement des classiques, et Fabien avait déjà produit un billet sur le sujet il y a quelques temps pour répondre aux mêmes interrogations.