Denis Dollfus' Blog

XP Day France c'est ce mois de mai

XP Day, c'est la conférence agile sur les méthodes agiles.

Ca se passe à Paris, et contrairement à ce que laisse entendre le nom de l'évènement, d'abord c'est sur deux jours, les 25 et 26 mai, et ensuite ça ne concerne pas qu'XP mais Scrum, Lean ou autres approches agiles du développement de logiciels.

Le programme est disponible sur le site xpday.fr, au passage on y notera le grand nombre (et la qualité) des sponsors.

Je suis aussi intrigué par des présentations qui sortent de l'ordinaire, tout particulièrement "le développement hédoniste", avec Michel Onfray en référence : l'agilité, à l'inverse des méthodes classiques, encouragerait à éviter le travail désagréable. Je le comprends comme ça : on évite la correction de bugs grâce aux tests unitaires, on évite les tâches répétitives grâce à l'automatisation et au code DRY, on collectione les retours gratifiants grâce aux livraisons fréquentes et finalement, grâce aux interactions constantes avec le client et le reste de l'équipe, on évite le travail de pure exécution qui consiste à suivre un plan défini à l'avance.

Moi ça me va, mais d'autres ne préfèrent-ils pas suivre un plan sans se poser trop de questions stressantes (c'est plan-plan) ?

Quelqu'un aurait-il à partager des comparaisons de turn-over entre équipe classique et équipe agile ?

Agilité des développeurs français : résultats de l'enquête

Le questionnaire sur les pratiques Agiles de management et d'ingénierie a été très bien accueilli puisque depuis sa mise en ligne le 6 janvier près de 270 personnes l'ont rempli. Il faut dire que  Claude Aubry, Olivier Azeau, David Brocard et Emmanuel Chenu ont donné à ce questionnaire une excellente visibilité.

En un coup d'oeil, voici les 270 scores portés sur les deux axes (voir plus bas pour la méthodologie) : 

 

Ce qui saute aux yeux, c'est que les résultats sont plutôt bons, il y a une accumulation de réponses vers les 100%.

Il apparait aussi une corrélation moyenne (0,7 pour les puristes) entre les deux dimensions.

En fait le nuage de points n'est pas symétrique. Il n'est pas rare que le répondant ait une bonne maîtrise des bonnes pratiques d'ingénierie sans que la gestion du projet dans lequel il travaille soit Agile. Pour caricaturer : il y a plus de développeurs Agiles travaillant dans un management rigide que l'inverse. Ce déséquilibre est clair quand on constate que la concentration de points sur l'axe des ordonnées n'a pas d'équivalent sur l'axe des abscisses.

Dans l'ensemble ces résultats, y compris cette disymétrie, sont encourageants pour ce qui est de l'adoption des méthodes agiles : les développeurs semblent prêts à adopter une gestion de projet Agile.

Qu'en pensez-vous ?

Bien sûr il y a des biais :

• L'enquête a été pour une grande part diffusée via des blogs orientés Agilité. Les répondants sont très probablement eux-mêmes sensibilisés aux méthodes Agile et peuvent tirer les scores vers le haut.
• Il est possible que certains répondants s'exercent à viser le 100%. Ca fait partie du côté pédagogique du questionnaire mais les scores peuvent en être biaisés.

Méthodologie. Chacune des 29 questions portait soit sur l'aspect "management/gestion de projet" de méthodes agiles (stand-up meeting, itérations courtes, estimation par les développeurs, etc.), soit sur la dimension "Ingénierie" (techniques pour garder le logiciel évolutif à moindre coût -- tests unitaires, refactoring, etc.). Une fois l'ensemble des questions traité, le profil du répondant correspond à une fraction d'un 100% théorique maximum sur ces deux axes. Ces profils sont portés sur le graphique ci-dessus, avec épaississement du point quand plusieurs profils sont superposés.

Chrome : portes ouvertes permanentes sur la compilation et les tests

(Marcel Gotlib,
Pervers Pépère)

Pour ceux qui douteraient encore (je sais qu'il y en a) de l'intérêt de l'intégration continue, c'est-à-dire de l'exécution périodique de la compilation et des tests unitaires de l'ensemble des modules d'une application, lisez-bien ce qui suit, vous allez en rester baba. Les autres, laissez tomber (je vous aurais prévenu).

Chrome, le nouveau navigateur open-source de Google est en développement. Soit, jusqu'ici ça va.

Mais attention : les processus de build qui tournent en ce moment même pour générer un composant de  Chromium pour XP, un morceau de WebKit pour Vista ou une extension pour Linux, tous ces process, mesdames et messieurs tenez-vous bien, y compris l'exécution des tests unitaires qui échouent, les compilations qui plantent, tout cela, c'est énorme, vous pouvez y accéder en permanence et en temps-réel à cette adresse !

Comme j'entends déjà les blasés me dire qu'ils le savaient déjà et que ça fait longtemps que ça se fait, je leur réponds en anticipant que, et d'un, ils n'auraient pas du lire ce billet rapport au premier paragraphe ce qui prouve bien qu'ils sont de mauvaise foi, et que ensuite, s'ils l'ont lu quand même c'est parce que l'illustration les a attiré ce qui prouve de surcroit leur qualité de geeks pervers.

Le pire, c'est qu'ils ont raison (Cf. FireFox -- et Eclipse me signale Aurélien dans les commentaires) mais moi ça m'épate encore quand je constate un tel niveau de transparence sur un projet d'une telle ampleur, et ça démontre que les pratiques d'ingénierie logicielle Agile peuvent s'appliquer à des gros projets. Ou plutôt l'inverse : les gros projets ne peuvent se passer des pratiques agiles, au moins celles-là.

Pour rappel l'intégration continue et les tests unitaires sont des composantes essentielles (mais pas les seules) d'eXtreme Programming (XP).

Puissance de calcul : la loi de Moore dans les mains des développeurs

Puissance multi-coeur

La prédiction de Moore, qui prévoit le doublement de la puissance de calcul des microprocesseurs tous les deux ans (libre interprétation de la formulation initiale de Moore dont le sujet était le nombre de transistors), est menacée par la réalité physique. C'est au software de secourir le hardware.

Problèmes physiques...

Les obstacles qui se dressent sur la route de la course à la puissance de calcul obligent AMD, Intel et autres fondeurs à chercher d'autres chemins que l'entassement de transistors ou l'accroissement des fréquences d'horloge :

• Mur de la puissance : augmenter encore le nombre de transistors présents sur une puce ou augmenter encore la fréquence d'horloge impose de savoir absorber le surplus de chaleur, alors que les solutions de refroidissement acceptables ont déjà été exploitées.
• Mur de la mémoire : un accès à la mémoire DRAM peut coûter quelques 300 cycles d'horloge du microprocesseur, au contraire de l'accès à la mémoire dite cache, embarquée sur la puce. Dépasser cette limite consiste à gonfler la mémoire cache de la puce, mais le mur de la puissance réapparaît...
• Mur de la complexité : paralléliser automatiquement le pipeline de traitement est une solution valable mais couteuse en termes de transistors car algorithmiquement complexe. Trouver de nouvelles astuces pour détecter à la volée les instructions parallélisables malgré la complexité du code et des données qui s'y rapportent est de moins en moins rentable et se heurte encore à la barrière de la dissipation de chaleur.

Plutôt que de se frotter à ces limites physiques, les fabricants de microprocesseurs préfèrent les contourner en jouant sur un tout autre paramètre, le parallélisme des fils d'exécution. Ce que font très bien les puces multi-cœurs.

... Solutions logicielles

Mais l'objectif de ces puces n'est atteint que si leurs multiples cœurs sont effectivement exploités. Autrement dit vu de l'utilisateur, le gain en confort n'est réel que si le logiciel manipulé consomme les possibilités de multithreading que le hardware lui offre.

Aujourd'hui c'est rarement le cas, d'une part parce que les logiciels actuels n'ont pas été conçus pour  ce type de hardware, et d'autre part parce que développer des logiciels multi-threadés est beaucoup plus difficile et donc beaucoup plus cher que de les développer "à l'ancienne", sans se soucier de parallélisme. Sans outils de développement adaptés, même un développeur expérimenté peut produire des bugs caractéristiques du multi-threading, souvent féroces (deadlock, crash) et difficiles à reproduire. Et bien sûr, ces bugs n'apparaissent en général que chez le client parce que celui-ci possède une configuration non testée (le dernier 256 cœurs à la mode…).

C'est pourquoi les librairies d'aide à la gestion du parallélisme sont indispensables aux développeurs soucieux de performances.

Pour .Net, ce sont les Parallel Extensions, qui feront partie de .Net 4.0 et qui sont en preview depuis décembre 2007. TPL, pour Task Parallel Library et  PLINQ, pour Parallel LINQ, font partie de ce package.

TPL permet par exemple de paralléliser une boucle (presque) sans risque d'erreur  avec Parallel.For :

    void Render(Scene scene, Color[,] rgb)

    {

        Parallel.For(0, screenHeight, delegate(int y)

        {

            for (int x = 0; x < screenWidth; x++)

            {

                rgb[x, y] = TraceRay(new Ray(scene, x, y));

            }

        });

    }

 

Pour le C++ natif, PPL (Parallel Pattern Livrary) sera inclus dans Visual Studio 2010.

Pour Java, Google vient de lancer la librairie open-source Korus, et les nouveautés de Java 7 API  comprendront des ajouts dans java.util.concurrency.

Voilà de quoi laisser le software prendre le relai du hardware dans la course à la puissance sans que les coûts de développement n'explosent.

Sources et liens :

• Design Considerations For Parallel Programming, MSDN Magazine octobre 2008.
• Microsoft Parallel Extensions to .NET Framework 3.5, June 2008 Community Technology Preview
• Parallel Computing Downloads

Agile tour 2008, le développement Agile près de chez vous

Pour mieux connaitre les méthodes de développement agiles, les experts des méthodes agiles viendront vous voir lors de l'Agile Tour 2008 qui passera par Besançon, Mulhouse, Genève, Grenoble, Lille, Toulouse et Valence, le tout du 1er au 23 octobre 2008.

Le programme de chaque étape est en voie d'être finalisé, mais il permet déjà de constater que les intervenants, qui représentent des entreprises de toute taille (de Yahoo à Octo en passant par Sfeir), seront clairement dans le concret des retours d'expérience. Une excellente occasion de les bombarder de questions.

Dépêchez-vous, pour Grenoble, c'est déjà complet.

http://www.agiletour.com

Clone Detective, détecteur de code dupliqué

La quantité de code dupliqué fournit sans doute un excellent indicateur (mais ni idéal, ni suffisant) de la qualité du code d'un logiciel.

On peut maintenant songer à industrialiser cette mesure avec Clone Detective. Clone Detective est un logiciel Open Source qui repose sur conQAT et propose une visualisation du code dupliqué intégrée à Visual Studio.

C'est ici : Clone Detective pour Visual Studio sur CodePlex

Fluent interface fashion victims

Les interfaces "qui nous parlent", ou Fluent Interfaces, sont à la mode, et comme toutes les modes IT on peut déjà prévoir qu'il y a aura des excès dont on aura à souffrir. Pour mémoire XML nous avait amené une épidémie de xml-ite aigue, caractérisée essentiellement par des noeuds XML en lieu et place des entités, des repository XML plutôt que des SGDB, et des transformations XSLT pour la logique métier et la création des vues. Sharepoint par exemple, dont la version beta que j'avais testée aux alentours de 2000 reposait largement sur XML/XSLT, commence à peine à s'en remettre.

A trop haute dose, quels peuvent être les effets indésirables des Fluent Interfaces ?

• Des interfaces tortueuses, difficiles à appréhender parce que passées au moule de la Fluent Interface sans que le domaine modélisé s'y prête. A titre d'exemple, une API de construction de documents XML gagne-t-elle à être "fluide" ? Pour ma part j'ai l'impression que le phrasé naturel amène un gain en lisibilité quand les sujets, verbes et compléments ont un sens précis (les Call() et Expect() de Rhino Mocks), moins quand ils sont génériques (les Nodes() et Attributes() d'un XML Builder).
• Un refactoring compromis. Une des bases des méthodes de développement agiles est le refactoring. Mais quand le code dupliqué se trouve enfoui au milieu d'une longue phrase fluente, il devient difficile de le factoriser. En tout cas les outils de refactoring intégré aux IDE, que ce soit Resharper ou le refactoring natif de Visual Studio ne peuvent pas appliquer un "extract method" sur ceci :

  XmlOutput xo = new XmlOutput()
      .XmlDeclaration()
      .Node("root").Within()
          .Node("user").Within()
              .Node("username").InnerText("orca")
              .Node("realname").InnerText("Mark S. Rasmussen")
              .Node("description").InnerText("I'll handle any escaping (like < & > for example) needs automagically.")
              .Node("articles").Within()
                  .Node("article").Attribute("id", "25").InnerText("Handling DBNulls")
                  .Node("article").Attribute("id", "26").InnerText("Accessing my privates")
                  .EndWithin()
              .Node("hobbies").Within()
                  .Node("hobby").InnerText("Fishing")
                  .Node("hobby").InnerText("Photography")
                  .Node("hobby").InnerText("Work");

  Ca devient aussi facile à refactorer qu'un roman aux phrases trop longues.
• Une lecture pas si évidente. Paradoxalement, il se pourrait bien que l'objectif initial de lisibilité soit manqué par excès de Fluent Interfaces. D'habitude (si seulement c'était une habitude), la lisibilité d'un logiciel est en grande partie déterminée par la clarté des noms de méthodes et de variables. Ou à défaut, et particulièrement dans le cas de méthodes trop longues candidates au refactoring, par des commentaires. Dans le cas d'une Fluent Interface, l'exemple précédent le montre bien, le risque est que le développeur se repose entièrement sur la "fluency" de l'API, et oublie les commentaires et le découpage en méthodes courtes et "parlantes".

Donc, à consommer avec modération, comme d'hab.

Fluent Interface : exercice

Suite à ce billet, voici ma première expérience (solutionVS 2008) avec les Fluent Interfaces. C'est une implémentation de l'exercice proposé par Michael Feathers, qui consiste à exposer les entiers sous forme littérale.

Exercice suffisant pour constater qu'il vaut mieux s'y aventurer avec méthode, ce qui n'a pas été mon cas. Dans l'implémentation que je vous propose, on peut aller jusqu'aux milliers, en écrivant des choses comme :

Assert.AreEqual(9210, FluentNumber.Nine.Thousand.Two.Hundred.And.Ten.ToInt());
Assert.AreEqual(92713, FluentNumber.Ninety.Two.Thousand.Seven.Hundred.And.Thirteen.ToInt());
Assert.AreEqual(700000, FluentNumber.Seven.Hundred.Thousand.ToInt());
Assert.AreEqual(777000, FluentNumber.Seven.Hundred.And.Seventy.Seven.Thousand.ToInt());
Assert.AreEqual(712713, FluentNumber.Seven.Hundred.And.Twelve.Thousand.Seven.Hundred.And.Thirteen.ToInt());
Assert.AreEqual(218001, FluentNumber.Two.Hundred.And.Eighteen.Thousand.One.ToInt());

Intellisense : pas trop mal, les 'teens' (thirteen, forteen...) n'apparaissent pas. Mais Hundred ne devrait pas apparaitre.

L'auto-completion fonctionne assez bien (cf. screenshot). Mais on peut quand même écrire des choses aberrantes :

FluentNumber.One.Thousand.One.Thousand.ToInt();

Pas facile à corriger... Etes-vous tenté par le défi ?

FluentNumbers.zip (VS 2008)

Fluent Interfaces (do you speak API ?)

Pour l'essentiel, le pattern des interfaces dites "fluentes" consiste à proposer aux développeurs d'écrire du code dont le phrasé ressemble au langage naturel.

Par exemple ce phrasé fluide (exemple tiré du site de Martin Fowler):

	TimeInterval meetingTime = fiveOClock.until(sixOClock);

exprime la même chose que cette version plus classique :

TimeInterval meetingTime = new TimeInterval(fiveOClock, sixOClock);

L'usage du mot 'until' (jusqu'à), courant dans la vraie vie, plutôt rare en programmation, fait la différence. De façon générale, les Fluent Interfaces privilégient l'emploient de méthodes au nom simples et issus du langage courant.

Deux exemples pour fixer les idées.

1. Rhino Mocks, framework open-source de mocks dynamiques développé par l'inévitable Ayende, permet d'écrire ça dans un test unitaire :

	Expect.Call(myObject.Concat("a","b")).Return("ab");

Joli non ?

Si on portait cette Fluent Interface en français, ça donnerait quelque chose comme :

 	JeMAttendsACeQue.CetAppel(monObjet.Concat("a","b")).Retourne("ab");

2. ReadableRex, API qui encapsule la complexité des expressions régulières :

    Regex socialSecurityNumberCheck = new Regex(Pattern.With.AtBeginning

            .Digit.Repeat.Exactly(3)

            .Literal("-").Repeat.Optional

            .Digit.Repeat.Exactly(2)

            .Literal("-").Repeat.Optional

            .Digit.Repeat.Exactly(4)

            .AtEnd);

Implémentation

Dans les grandes lignes, l'implémentation d'une Fluent Interface en elle-même n'a rien de sorcier et consiste souvent à retourner dans les méthodes et accesseurs le contexte en construction. Par exemple :

	public class Configuration
	{
		string color;
		int height;
		Configuration Color(string color)
		{
			this.color = color;
			return this;
		}
		Configuration Height(int height)
		{
			this.height = height;
			return this;
		}
	}

Dans le détail, développer une Fluent Interface peut s'avérer extrémement complexe. La complexité tient à l'inconsistance fréquente du langage naturel. Qu'il s'agisse de l'anglais ou du français, la grammaire qui le définit regorge de contradictions, d'exceptions et d'effets de contexte.

Défi

Pour vous en convaincre, essayez d'implémenter une API fluente d'expression des nombres littéraux tel celui suggéré par Michael Feathers, et dont voici un aperçu des spécifications :

  Assert.AreEqual(1, (int)FluentNumber.One);
  Assert.AreEqual(23, (int)FluentNumber.Twenty.Three);
  Assert.AreEqual(912, (int)FluentNumber.Nine.Hundred.And.Twelve);
  Assert.AreEqual(777000, (int)FluentNumber.Seven.Hundred.And.Seventy.Seven.Thousand);

Ce que ne dit pas cet essemble de tests à faire réussir, c'est que l'autocompletion doit aussi fonctionner au mieux : taper 'Twenty' doit déclencher les propositions 'One', 'Two', ... 'Thousand" et 'Hundred', mais ni "Twenty" et autres dizaine, ni 'Thirteen' et autres 'teens'. C'est sûrement un excellent exercice pour appréhender les difficultés de développement d'une Fluent Interface.

Serez-vous capable de développer une API robuste vis-à-vis des tournures aberrantes telles que

	FluentNumber.One.Thousand.One.Thousand

Un vrai travail de linguiste...

Liens :

• Martin Fowler, Fluent interface
• Ayende, Rhino Mocks
• Joshua Flanagan, readable regular expressions

Visualiser en vidéo les commits d'un projet de développement

Les centaines (milliers ?) de commits du projet Eclipse visualisés en une vidéo de quelques secondes... Forcément intéressant.

code_swarm - Eclipse (short ver.) from Michael Ogawa on Vimeo.

Source : code_swarm, an experiment in organic software visualization via le blog de Max Kiesler Latest DesignDemos.