L'Agilitateur - En français

Soft(ware)Ball

Oaz — Thu, 09 May 2013 19:42:00 +0200

Software development is a cooperative game of invention and communication
J'en arrive à penser que cette phrase d'Alistair Cockburn définit l'essence du développement logiciel.

Oui, développer un logiciel c'est jouer à un jeu.
Sans vouloir paraphraser Agile Software Development: The Cooperative Game qui l'explique bien mieux que je ne pourrais le faire, le développement logiciel est un jeu coopératif dont l'objectif est de mettre en production un système.

C'est réellement un jeu coopératif, c'est à dire un jeu où tous les joueurs gagnent ou perdent ensemble. Par tous les joueurs on entend les clients, les développeurs, etc. C'est d'ailleurs ce que nous rappelle le manifeste agile : la collaboration avec les clients plus que la négociation contractuelle.

Le développement logiciel est un jeu car son issue est incertaine. Même si on élabore une stratégie et que, plus localement, on fait appel à diverses tactiques, on ne peut gagner que par l’adaptation au changement plus que le suivi d’un plan.

La communication entre les divers joueurs tient un rôle primordial. C'est pour cela que l'on valorise les individus et leurs interactions plus que les processus et les outils.

Toutes ces notions sont importantes, et il n'est pas étonnant de voir aujourd'hui se développer leur apprentissage à travers le jeu. On joue à des jeux pour reproduire en quelques minutes ou en quelques heures les mêmes mécanismes de coopération, communication et adaptation au changement que l'on retrouve en grandeur réelle dans le jeu du développement logiciel.

Soft(ware)Ball est un jeu qui s'inscrit dans cette lignée. Mais alors, pourquoi proposer un jeu de plus s'il en existe déjà tant ?
A cause de la valeur manquante du manifeste, celle qui met en avant le logiciel opérationnel. La conception d'un logiciel implique l'invention et la combinaison de certains mécanismes. Même s'il y a une part importante de créativité dans certains jeux, celle-ci ne ressemble que rarement à celle mise en oeuvre dans le développement logiciel.

Durant les trois dernières années, j'ai animé des ateliers Stub et Mock montent sur scène et Si t'es pas SOLID, t'es pas agile pour faire découvrir certains principes et pratiques de développement logiciel. Ils avaient en commun le fait d'utiliser des "composants humains" pour assembler un logiciel. Cette approche a le double mérite de pouvoir faire de la programmation (et donc d'inventer des mécanismes) dans un temps relativement réduit et sans connaissance particulière d'un langage informatique.
Soft(ware)Ball reprend cette idée^[1] pour devenir un jeu coopératif de communication et d'invention.

Vous pourrez découvrir Soft(ware)Ball (et surtout y jouer)

En avant première, lors d'un atelier organisé par Agile Toulouse le 16 mai 2013.
A la conférence Agile France à Paris les 23 et 24 mai 2013.
Au Scrum Gathering Paris les 23, 24 et 25 septembre 2013.

Plus d'infos à propos du jeu seront ultérieurement disponibles sur http://www.softwareball.org/

Notes

[1] en fait, il reprend même le principe et les règles de Si t'es pas SOLID, t'es pas agile

En revenant de Mix-IT 2013

Oaz — Mon, 29 Apr 2013 15:05:00 +0200

Jeudi et vendredi, j'étais à Lyon où j'ai, pour la première fois, participé à Mix-IT.
Merci aux organisateurs pour ces deux superbes journées.

Ce qui était bien, voire très bien

Le parallèle entre le théâtre et le développement logiciel dans la session Collaborer, et si on improvisait? de Vincent Daviet. Ce fut, sans le moindre doute, ma session préférée de ces deux jours. Tous les ingrédients étaient là pour transformer en une heure un groupe de personnes qui ne se connaissaient pas, ou peu, en une équipe soudée : collaboration, communication, création, confiance...
Les bonnes pratiques de conception d'une API web dans la session-débat animée par David Larlet et Eric Daspet. Malgré une logistique peu adaptée, j'ai bien aimé la manière dont était menée la discussion avec cette mise en danger inévitable lorsqu'on donne à l'assistance la possibilité de s'exprimer longuement.
Le rôle de l'architecte logiciel dans Software architecture for developers de Simon Brown. Une session menée à un rythme incroyable. Même si je n'y ai pas appris grand chose, la description d'un architecte logiciel qui doit sortir de sa tour d'ivoire pour être sur le terrain fait toujours plaisir à entendre.
L'importance de l'environnement pour faire une bon produit dans The product is the byproduct de Zach Holman. Une session très bien calibrée et sans grande surprise. La vision "de l'intérieur" de la société Github est intéressante. Est-ce que cette approche est transposable partout ? La question reste ouverte...
La possibilité de se lancer dans Scala. Dans cet atelier^[1] de Ludwine Probst, Jean Helou et Mathieu Chataigner, j'ai pu découvrir les bases de la programmation fonctionnelle en Scala. Le nombre d'exercices proposés est conséquent. Il est difficile d'arriver aux exercices vraiment intéressants dans le peu de temps disponible mais on peut continuer à la maison.
La session déjantée sur l'apprentissage de la programmation aux enfants. Audrey Neveu et Aline Paponaud ont conclu ces deux jours dans la bonne humeur. C'est un sujet important qui méritait une telle mise en avant. Paradoxalement, j'ai l'impression qu'il est plus difficile de se lancer dans la programmation qu'il y a 30 ans lorsque j'étais ado. A l'époque, programmer était presque un passage obligé même si on commençait par recopier du code sans le comprendre. Aujourd'hui, un ordinateur sait faire tant de choses "tout seul" qu'il en faut beaucoup plus pour montrer l'intérêt d'écrire un programme qui n'arrivera jamais à la cheville de ce qui est déjà là à portée de clic - et je parle ici en tant que père de trois filles qui ont déjà eu Scratch entre les mains.
Les retours que j'ai eus pour Deux ans dans le flux. Ma session a été extrêmement bien accueillie. Je remercie ici ceux qui ont tweeté tout le bien qu'ils en pensaient. S'il y en a qui veulent continuer à discuter de branche unique, de prévisions probabilistes ou de quoi que ce soit d'autre, vous savez où me joindre !
L'accueil réservé aux orateurs. J'ai eu la chance de voir une partie de l'envers du décor et l'attention portée à ceux qui viennent pour seulement partager leurs connaissances et leurs expériences avec leurs pairs -c'est en tout cas comme ça que j'envisage les choses- était bien au delà de mes attentes.
Les rencontres. C'est finalement le plus important : créer des occasions d'échange entre personnes venues d'horizons variés^[2]. La chevauchée en vélo'v dans les rues de Lyon à une heure du mat est une option recommandée.

Ce qui aurait pu être mieux

La description des sessions. J'ai quelquefois été surpris par un contenu qui ne correspondait pas à l'idée que j'avais en tête en lisant la description. Au final, l'intérêt pour la session est toujours là mais on peut toujours faire mieux.
Une meilleure logistique dans quelques cas bien précis : la retransmission des keynotes dans la 2ème salle ; la sonorisation générale de l'ensemble. La mauvaise accoustique générale des salles et le ronronnement (des climatiseurs ?) imposait l'usage de micros qui n'étaient pas toujours au rendez-vous ni très bien réglés.
Les cercles d'habitués qui ne favorisent pas les échanges. J'ai surtout ressenti cela lors de la soirée orateurs précédant l'évènement et durant la première journée. Après la soirée du jeudi, ça allait un peu mieux. L'existence de communautés "java" et "agile" réunies pour l'occasion n'est pas étrangère à cela. Il y a encore du boulot pour réellement décloisonner.
L'obsession des détails techniques dans certaines sessions ou discussions. Je veux bien que le problème des "null pointer" dans java soit important mais de là à s'éterniser dessus... (on a du y passer près de 10 minutes dans la session sur Kotlin) J'ai l'impression que (en lien avec le point précédent) l'obsession inutile pour les détails techniques qui semble exister dans une partie de la communauté "java" n'a d'égale que la négligence pour ces mêmes détails dans une partie de la communauté "agile".
Les hamburgers du Blogg qui mettent deux heures à arriver au lieu de la demi-heure annoncée.

Les questions (que je me suis) posées

Au delà de proposer plusieurs paradigmes de programmation avec un langage unique, Scala permet-il de mixer les paradigmes pour que l'ensemble soit plus intéressant que la somme de chacun d'entre eux pris séparément ?
Mais qu'est-ce qu'ils ont tous ces développeurs java à parler sans arrêt de Null Pointer Exception ?
Comment faire comprendre l'intérêt de la branche unique de développement sans faire sauter au plafond la moitié de la salle ?
Qu'est ce qu'une API ?

Les lecons (re-)apprises

La distinction architecte/développeur ne devrait pas exister
Toute activité assimilable à un jeu collaboratif de communication et d'invention a beaucoup de choses en commun avec le développement logiciel
Une API web doit renvoyer des identifiants web. Il ne faut pas avoir de client spécifique pour les interpréter.

Les supports des diverses sessions et l'ensemble des compte-rendus sont disponibles sur le site de l'évènement.

Notes

[1] pour faire bien il faut, en fait, dire "hands-on"

[2] J'essaie de lister ici toutes les personnes avec lesquelles j'ai pu échanger quelques mots - et dont je me souviens du nom. Si vous n'y êtes pas, faites-le moi savoir ! Alfred, André, Antoine, Camille, Caroline, Christophe, Ellène, Emilie, Eric, Eric, Franck, Guillaume, Haïkel, Jean-Laurent, Jean-Louis, Jerôme, Jonathan, Laurent, Laurent, Lionel, Marianne, Matthieu, Nicolas, Nicolas, Rémy, Romain, Sarah, Stéphane, Thierry, Ursula, Xavier

Un code propre est plus utile qu'un code efficace

Oaz — Sun, 07 Apr 2013 14:44:00 +0200

Il fut un temps, avant que le développement de logiciels ne devienne mon métier, où la qualité d'un programme se jugeait, à mes yeux, à son efficacité : rapidité d'exécution, faible occupation mémoire, compacité du code^[1]... Mais ça c'était avant. Je suis depuis longtemps convaincu que la clarté et la lisibilité sont des critères incomparablement supérieurs.
Est-ce un changement de point de vue dû à l'expérience ?

Dans une discussion sur le groupe google "Software Craftsmanship" intitulée "Optimizing for code readability vs efficiency", l'auteur initial explique que ses étudiants sont beaucoup plus attachés à l'efficacité et que faire passer le message d'une meilleure lisibilité n'est pas une tache aisée. Et pourtant, une meilleure lisibilité est souvent un passage obligé vers une meilleure efficacité comme le confirment plusieurs intervenants de la discussion.
Pourquoi ce message est-il si difficile à faire passer ?

Je voudrais apporter ici ma pierre à l'édifice. Je suis parti d'un défi de programmation sur codingame.com, celui de janvier 2013 nommé "La résistance"^[2], et j'ai essayé de l'implémenter en pilotant mon développement par les tests, en favorisant la clarté de la conception et sans jamais essayer d'optimiser prématurément.

Il s'agit de décoder un message en morse, potentiellement très long (plusieurs milliers de signes 'point' et 'tiret') et dont les séparateurs entre les mots ne sont pas connus. On dispose pour cela d'un lexique des mots possibles (là aussi potentiellement plusieurs milliers de mots différents). Et on s'attend bien évidemment à ce que ce décodage soit très rapide.
Une précision s'impose avant d'entrer dans le sujet. La résolution de ce problème nécessite un choix de stratégie algorithmique. Ce n'est pas le TDD qui va me faire découvrir comme par magie la bonne stratégie à adopter.^[3] La création d'algorithmes, ça relève du domaine de l'informatique théorique, pas du développement logiciel. Le TDD, lui, va me permettre d'implémenter le plus proprement possible l'approche que je choisirai.
Ceci étant acquis, mon choix se porte sur la stratégie la plus intuitive et faisant l'usage minimal de notions compliquées : parcourir de gauche à droite le message morse en recherchant toutes les solutions possibles.

Je commence par implémenter quelques fonctions utilitaires pour représenter une séquence morse et faire les conversions adéquates avec les chaînes de caractères. Rien de passionnant.
Le vrai boulot démarre en top-down. Je définis l'abstraction qui va me permettre de décoder un message morse : renvoyer un ensemble de toutes les séquences de mots correspondant à un message morse donné.

public enum Morse
{
  Dot,
  Dash
}

public interface IDecodeMessage
{
  IEnumerable<IEnumerable<string>> Decode (IEnumerable<Morse> message);
}

Je commence à piloter l'implémentation en utilisant les jeux de tests fournis par codingame.com. Il est important d'écrire les tests en utilisant des notions stables, en l'occurrence mes tests portent uniquement sur le contrat "I Decode Message" et ne font jamais appel à des détails d'implémentation. J'avais expliqué cette approche dans "Chacun cherche son TDD".
En faisant évoluer la méthode "Decode", je vois très rapidement un autre concept apparaître. C'est dû à l'aspect "organique" de la conception émergente (évoqué par ailleurs dans "Le logiciel, un organisme multicellulaire ?"). Une opération élémentaire de mon implémentation consiste à rechercher tous les mots du dictionnaire qui sont des candidats potentiels pour débuter une séquence morse donnée. Cette opération devient donc un contrat "I Find Words" dont l'implémentation sera découplée du décodage.
A cet instant je me retrouve avec un jeu d'interfaces qui restera stable pour le reste du développement (mais ça je ne le saurai qu'à la fin) :

public interface IDecodeMessage
{
  IEnumerable<IEnumerable<string>> Decode (IEnumerable<Morse> message, IFindWords thesaurus); 
  long Count (IEnumerable<Morse> message, IFindWords thesaurus);
}

public struct Starting
{
  public string Word;
  public int MorseLength;
}
  
public interface IFindWords
{
  IEnumerable<Starting> GetWordsStarting (IEnumerable<Morse> sequence);
}

On notera deux choses :

J'ai rajouté une méthode "Count" dans "I Decode Message". L'énoncé du défi ne porte que sur la détermination du nombre de solutions. Toutefois, dans la vraie vie, on sera plus intéressé par les résultats du décodage. Je fais donc le choix d'implémenter les deux aspects du problème.
La méthode "GetWordsStarting" du contrat "I Find Words" renvoie l'ensemble des mots qui pourraient se trouver au début de la séquence de morse donnée. Pour chacun de ces mots, elle renvoie aussi le nombre de signaux morse consommés dans la séquence.

A partir de là il faut faire un choix de priorité : continuer sur l'implémentation du décodage ou se focaliser sur la recherche de mots.
Je choisis une solution intermédiaire. Je vais écrire une implémentation simpliste de "I Find Words". Si elle est assez efficace, tant mieux, sinon elle me servira de fake pour écrire le décodage.
Je transforme ma panoplie de tests pour en créer une adaptée à "I Find Words" et j'écris une implémentation basique. Elle contient la liste des mots du dictionnaire et, pour chacun d'entre eux, la chaîne de caractères correspondant au code morse. A chaque appel de "GetWordsStarting", la liste entière est parcourue et les mots sont détectés par simple comparaison de chaînes de caractères morse. On peut sûrement faire plus efficace mais c'est simple et ça fonctionne - et c'est tout ce qui m'importe pour l'instant.

Je peux alors attaquer la partie décodage. A partir du jeu de tests initié précédemment, j'écris un décodeur qui procède par recherche en profondeur. Un curseur définit la profondeur courante et des appels récursifs permettent d'explorer les profondeurs suivantes. Un mécanisme de typage générique me permet de factoriser le code de recherche qui est désormais commun au décodage complet et à leur simple dénombrement.

Exemple : ......-...-..---.-----.-..-..-.. avec les mots HELL, HELLO, OWORLD, WORLD

Niveau 1
| ......-...-..---.-----.-..-..-..
| H   EL   L       ==> 2a
| H   EL   L   O   ==> 2b

Niveau 2a
| ......-...-.. | ---.-----.-..-..-..
| H   EL   L    | O  W  O  R  L   D

Niveau 2b
| ......-...-..--- | .-----.-..-..-..
| H   EL   L   O   | W  O  R  L   D

Sur des petits tests, tout cela fonctionne parfaitement. Cela se complique lorsque j'écris un test qui dénombre 65536 solutions car celui-ci prend près de 4 secondes pour sortir le résultat. J'ai deux pistes possibles d'optimisation : la recherche des mots ou le parcours en profondeur.
Je choisis de rester sur ce dernier car il me vient l'idée de mémoriser les résultats obtenus pour éviter de nombreux appels récursifs^[4]. Pour cela j'écris une classe d'implémentation différente pour le même contrat "I Decode Message" mais cette fois en ajoutant un mécanisme de cache. Au fil de l'écriture, j'arriverai à mettre en commun une majorité de code entre les deux implémentations de parcours en profondeur.

Ce choix fait des merveilles. Le test qui passait en 4 secondes^[5] tombe à 35 millisecondes^[6]. Je peux alors attaquer le plus gros test fourni par le défi. Il contient un dictionnaire d'environ 10000 mots et il demande le décodage d'une séquence morse d'environ 10000 signes pour trouver un total de 57330892800 combinaisons.
Et là c'est la claque : le test passe en plus de 40 secondes. Heureusement que je n'ai pas commencé par ce test avec l'implémentation sans cache car elle serait probablement encore en train de tourner...

Il me reste une dernière piste d'amélioration : la recherche de mots. J'essaie d'utiliser une structure de donnée classique lorsqu'on veut avoir des recherches plus rapides : l'arbre.
Comme le montre le diagramme ci-dessous, je place les mots du dictionnaire dans une structure où, en partant de la racine, peuvent être rapidement trouvés tous les mots commençant une séquence de morse donnée. Par exemple, une séquence "dash dot" me donnera les mots "T", "TE" et "N" (s'ils font partie du dictionnaire, bien évidemment).

Ce dictionnaire en arbre est donc une implémentation alternative de "I Find Words".
Et le test qui prenait plus de 40 secondes^[7] tombe à 130 millisecondes^[8].

La démarche et les chiffres parlent d'eux-mêmes.
Une stratégie algorithmique étant fixée, le TDD et une approche du code systématiquement claire et lisible mettent en évidence les concepts importants d'un logiciel. Et en se basant sur ces concepts et les tests qui y sont associés, on peut bâtir, lorsqu'elle devient nécessaire, une stratégie d'optimisation pour rendre le logiciel plus efficace.
Cette approche est d'autant plus importante que

un logiciel évolue rarement dans un environnement figé. Dans l'exemple que l'on vient de voir, on pourrait, par exemple, imaginer un dictionnaire initialement chargé en mémoire à partir d'un fichier qui, du fait de sa mise à jour continuelle, évolue en un dictionnaire stocké dans une base de données. L'implémentation de "I Find Words" serait alors spécifique à notre base de données et indépendante des avancées réalisées sur la partie parcours en profondeur.
un logiciel n'a que rarement des fonctionnalités immuables. Toujours dans le logiciel ici présent, on pourrait imaginer un décodage des phrases qui tiendrait compte d'un contexte sémantique (par exemple, tel mot ne peut pas être suivi de tel ou tel autre mot). Là encore, il faudrait envisager des modifications qui seront d'autant plus aisées que les composants présents sont faiblement couplés.

Ecrire un logiciel ce n'est pas écrire un algorithme. On a besoin des fondements théoriques que la science informatique peut nous apporter sur les divers types d'algorithmes, sur leur complexité... Mais écrire un logiciel c'est se placer dans un contexte mouvant en vue de réaliser et faire évoluer un produit pour un utilisateur.
La plupart du temps cela nécessite de donner la priorité absolue à la maintenabilité du code. Il faut donc le garder propre car, dans la durée, c'est le seul moyen pour qu'il reste efficace.

Le code source complet en C# utilisé dans le billet est disponible sur github à l'adresse https://github.com/Oaz/Resistance/tree/code_propre.
Le schéma ci-dessous présente les principales interfaces et classes de ce code source.

Notes

[1] A titre d'exemple, voici un bout de code écrit en 1985

[2] Merci à Jérôme pour m'en avoir indirectement donné l'idée

[3] Rappelons-nous cette comparaison entre le TDD de Ron Jeffries et le code (difficile à lire et impossible à maintenir) de Peter Norvig qui utilise une toute autre approche pour résoudre un sudoku.

[4] un langage de programmation qui se rendrait compte que je n'utilise que des fonctions pures et des objets non mutables m'aurait peut être évité cette étape car il ne relancerait pas le calcul d'une même fonction avec les mêmes paramètres

[5] voir test DeepSearch/3c/Dumb

[6] voir test CachedDeepSearch/3c/Dumb

[7] voir test CachedDeepSearch/4/Dumb

[8] voir test CachedDeepSearch/4/Tree

Qui a besoin de plusieurs branches ?

Oaz — Tue, 02 Apr 2013 07:59:00 +0200

Si les logiciels de gestion de versions sont globalement rentrés dans les habitudes de tout développement logiciel, la façon de les utiliser est loin d'être uniforme. Cette multiplicité des usages est particulièrement flagrante lorsque l'on évoque la notion de branches.
Wikipedia définit ainsi les branches :

Lorsque des modifications divergentes interviennent hors conflit, il se crée des branches. Le fait de vouloir rassembler deux branches est une fusion de branches.

Les branches sont utilisées pour permettre :
la maintenance d'anciennes versions du logiciel (sur les branches) tout en continuant le développement des futures versions (sur le tronc) ;
le développement parallèle de plusieurs fonctionnalités volumineuses sans bloquer le travail quotidien sur les autres fonctionnalités.

La nécessité de maintenir plusieurs versions livrées d'un même logiciel est un besoin courant dès que le logiciel est proposé à plusieurs clients .Un nouveau client est intéressé par la version 4.0 qui vient tout juste de sortir tandis qu'un autre préfére rester sur la 3.2 sur laquelle il a investi beaucoup de temps de formation. Le coût de passage à une nouvelle version majeure serait prohibitif. Du coup l'équipe de développement doit simultanément développer la version courante et corriger les bugs trouvés sur des versions plus anciennes. Pour cela, on travaille avec des release branches.
Par ailleurs, le développement d'une fonctionnalité ne peut pas se faire du jour au lendemain. Cette même équipe, en développant la version 4.0 ne peut pas se contenter de ne travailler que sur les fonctionnalités en cours. Il y a cette future fonctionnalité que tant de clients attendent et qui sortira, si tout va bien, dans la version 4.5 ou, au pire, l'an prochain dans la 5.0. Et cette fonctionnalité prend tant de temps à mettre en oeuvre qu'il faut d'ores et déjà y travailler. Mais on ne peut pas le faire sur la version courante. On va donc utiliser une feature branch qui sera fusionnée ultérieurement avec la version courante du moment.

Ce scénario vous semble familier ?
C'est le lot de nombreuses équipes pour qui le contrôle de version est devenu une des pierres angulaires de leur processus de développement et occupe une part non négligeable de leur activité quotidienne.

L'émergence récente des outils de gestion de version décentralisés facilite grandement la tache de ces équipes.
Historiquement, avec les gestions de version centralisées, les branches sont coûteuses. Il faut demander au serveur de créer une branche, ce qu'il va faire en copiant plus ou moins intelligemment les données d'un dossier dans un autre dossier. En fait, dans une approche centralisée, diverger du point central est l'exception. On s'attend à ce que le développeur rapporte au plus vite sa production sur le serveur et résolve les conflits pouvant intervenir avec la production des autres développeurs.
Dans les outils décentralisés, les branches sont en quelque sorte incluse dans l'ADN. On s'attend à ce que des divergences surviennent et on met en place les fonctionnalités permettant de les fusionner au mieux, de piocher ici ou là des modifications individuelles. Bref on n'a pas peur des branches et on les accueille avec plaisir.

Sauf que...
Comme disait l'autre, si ton seul outil est un marteau, tu verras tous les problèmes comme des clous...
J'ai la désagréable impression que, les outils décentralisés ayant le vent en poupe dans les usages, l'utilisation à outrance de branches pour la moindre raison devrait aller de soi parce que c'est devenu si simple de les manipuler...
On ne peut nier que Linus Torvalds ait besoin de git parce qu'il travaille indirectement avec des centaines de personnes et qu'il ne fait confiance^[1] à quasiment aucune d'entre elles. Le modèle décentralisé semble la réponse idéale aux gros projets open source.
Mais qui a des besoins vaguement similaires ?

Les branches de release ne sont pas une fatalité. Un logiciel peut évoluer jour après jour sans véritable version majeure en étant continuellement livré à ses clients. Si certaines fonctionnalité sont trop dures à avaler immédiatement, on imagine des mécanismes de configuration pour les activer à la demande.
Les branches de feature ne sont pas une fatalité. Les mêmes mécanismes de configuration sont utilisés pour des fonctionnalité non terminées : leur code sera présent mais non exécuté dans la version livrée.

Pourquoi mettre tout son effort dans l'utilisation avancée d'un gestionnaire de version pour atteindre ces objectifs alors que la richesse des langages de développement nous permet de réaliser la même chose à l'intérieur du logiciel lui-même ?
On parle de plus en plus de feature flipping, c'est à dire de la capacité à activer/désactiver une fonctionnalité via une option configuration. Mais je crois que ceci n'est que la partie émergée de l'iceberg à venir.
Un flag de configuration qui induit une armée de "ifs" à divers endroits du code en fonction de la fonctionnalité à maintenir n'ira jamais bien loin. Diverses techniques permettent toutefois de se débarrasser des ifs. On peut arriver à un feature swapping extrêmement maintenable avec du polymorphisme et de l'injection de dépendance.
Bref, une meilleure approche de la conception logicielle rend le concept de branche obsolète.

Mais on peut aller plus loin.
Dans une équipe agile, donc à taille humaine, où la confiance est inconditionnelle et où l'on pratique sans relâche la propriété collective de code, les feature branches n'ont pas d'intérêt car tout le monde travaille sur la même chose avec des échéances très courtes. Tous les membres de l'équipe modifient donc plusieurs fois par jour la version de référence du logiciel.
Si on englobe dans le concept les utilisateurs du logiciel, on laisse également tomber les release branches car l'utilisateur n'a que faire de l'existence de plusieurs versions. Il veut seulement utiliser facilement et rapidement la meilleure version qui soit.

Dans mon équipe, la branche unique est devenue un facteur important qui nous permet de développer sereinement et continuellement notre logiciel depuis plusieurs années. C'est ce dont je parlerai, entre autres choses, dans la session "Deux ans dans le flux" lors du prochain Mix-IT.

Notes

[1] peut être à juste titre mais c'est une autre histoire

Mix-IT 2013

Oaz — Sat, 16 Mar 2013 18:34:00 +0100

Les 25 et 26 avril prochains se déroulera à Lyon la 3ème édition de Mix-IT.
Et je suis très content de pouvoir, pour la première fois, y assister car je suis persuadé que c'est exactement le genre d'évènement dont a besoin le monde du développement logiciel.

Il existe des évènements très orientés technique sur tel ou telle langage ou technologie (logiciel libre, microsoft, web, java...) Il en existe d'autres sur les aspects organisationnels du développement logiciel, avec nombre d'entre eux dédiés à l'agilité. Les frontières ne sont bien évidemment pas hermétiques : on trouvera toujours quelques sessions parlant de méthodes agiles à DevoxxFR ou aux Tech Days tout comme on trouvera quelques ateliers où l'on écrit du code dans l'Agile Tour. Mais deux jours de conférences et ateliers où l'on trouve un certain équilibre entre tous les aspects du développement logiciel, je crois que ça reste unique en France ^[1].
Le développement logiciel est une discipline où l'on ne peut pas se contenter de maîtriser à fond les technos sans avoir conscience du rôle essentiel que joue l'aspect humain. C'est aussi une discipline où, même si on n'est pas développeur, on ne peut pas se permettre d'être ignare sur ce qu'est le code. Ce sera un plaisir d'aller à une conférence sans être obligé de laisser la moitié du cerveau à la maison...

La cerise sur le gâteau, c'est que, sachant que j'allais assister à Mix-IT 2013, j'ai proposé deux sessions et l'une d'entre elles a été retenue. \o/

Et, puisque le planning est sorti, je suis allé y jeter un coup d'oeil pour commencer à faire quelques choix.

Jeudi.
A 9h30, je me laisserais bien tenter par un découpage en petits morceaux mais je ne suis pas sûr d'avoir envie d'attaquer directement avec un atelier. Il y a aussi le langage Kotlin qui retient mon attention parce que je n'ai pas encore trouvé de langage qui me permette de prendre une JVM sans regretter mon C# préféré. A 11h00, il y a ce "Validated Influencing" qui m'intrigue. Je pourrais aussi plonger dans Kotlin mais je compte voyager léger, donc sans laptop.
A 13h30, la question ne se pose pas. A 15h00, non plus. J'ai eu l'occasion de voir la première d'Agile Unlimited l'an dernier à Agile Toulouse donc, pour ce créneau horaire, je choisis sans hésiter un live coding qui pourrait peut être me permettre de satisfaire un besoin que j'ai à court terme.
A 16h30, c'est le premier moment de la journée où aucune session ne m'attire plus particulièrement qu'une autre... Je verrai en fonction de l'humeur du moment. Par contre, à 18h00, le choix est déjà fait : ce sera le développement piloté par l'API (car j'ai en tête un embryon de conférence sur un sujet connexe). L'architecture agile m'intéresse également mais je pourrai probablement la revoir du côté de Toulouse ou pas loin.

Vendredi.
J'ai bien envie de démarrer la journée avec du théâtre parce que je n'avais pas pu assister à cet atelier à Agile Grenoble (et ses 9 tracks en parallèle...) et de la poursuivre avec un management vraiment agile parce que la tentation du command & control plane toujours.
Après le repas, j'essaierai d'aller faire quelques dessins d'architecture logicielle. Je suis curieux de voir comment formaliser des schémas en abandonnant UML.
A 15h, j'irai découvrir comment faire de l'UX sans UXer, ce qui tombe plutôt bien car il n'y a pas vraiment de compétence UX dans notre équipe... Et pour finir la journée j'irai peut être participer au Challenge Kanban, à moins que je ne me laisse tenter par le robot Nao.

Bref, j'ai déjà hâte d'y être.

Notes

[1] les commentaires sont là pour me contredire le cas échéant

Agile Grenoble 2012, ma journée chez les binômes

Oaz — Sat, 10 Nov 2012 10:22:00 +0100

J'assistais jeudi pour la première fois à Agile Grenoble.

Ce qui était bien

Le binôme Rémy Sanlaville/Johan Martinsson et leur refactoring du Gilded Rose Kata chez les développeurs anonymes. Près de 70 personnes dans une salle prévue pour 40 (ne jamais sous-estimer l'attrait d'une session pour développeurs) et un public assez enthousiaste comme l'indiquait le ROTI à la sortie de la salle.
Le binôme Emmanuel Gaillot/Jonathan Perret pour leur évocation des travers du pair programming. Là encore la (même) salle est plus que comble même si le public semble avoir moins accroché. Pour ma part, je me suis régalé. Il fallait peut-être avoir un minimum de recul sur la pratique pour apprécier pleinement la session contrairement à la précédente qui pouvait mieux parler à tous les développeurs ? Et j'en profite pour souhaiter une bonne continuation à ut7.
Le binôme Christophe Grand/Laurent Petit et leur introduction au langage Clojure. J'ai trouvé le rythme de la session un peu trop lent à mon goût mais je suis très content d'y avoir participé car je ne connaissais pas du tout le langage. Et, surtout, je n'ai pas été surpris par leur style de conception ce qui me conforte dans mon approche pour l'instant très limitée des langages fonctionnels.
La keynote de Gojko Adzic. Elle n'apportait rien de fondamental pour qui a lu quelques uns de ses articles mais elle faisait plaisir à voir. Une vraie keynote : des idées fortes, un rythme soutenu, quelques exemples biens choisis, bref, un bon moment.
La logistique. Un vestiaire qui m'a bien dépanné. Un repas bien au dessus de ce que l'on a à Agile Tour Toulouse et pour, parait-il, un coût moindre...

Ce qui était moins bien

Le nombre de sessions en parallèle. Neuf, c'est définitivement beaucoup trop pour ce genre de conférence où il est généralement difficile de se faire une idée du contenu exact des sessions. Et, le pire, c'est qu'il n'y avait absolument aucune classification ou thématique associée à chaque session. Bref, un vrai labyrinthe. Je me suis rabattu sur ce qui m'avait l'air le plus technique possible pour éviter de perdre mon temps.
Un retour d'expérience de la Société Générale déguisé en keynote pour débuter l'après-midi. Ca a sûrement intéressé des gens mais de là à l'imposer à tout le monde... En plus impossible pour moi de sortir sans faire se lever 5 ou 6 personnes...
Le retour d'expérience de Laurent Sarazzin (celui de la keynote subie donc). Tant qu'à être là j'ai, difficilement, essayé d'écouter cet improbable sac de noeuds. Passons sur "la boite à cons" dont le terme me semble particulièrement mal choisi (c'est un "coach" qui a inventé ce nom ?). Je retiendrai cette phrase qui m'a choqué : "les managers deviennent des story tellers". Impossible pour moi d'imaginer un voyage vers l'agilité via des techniques à la frontière de la manipulation mentale. Bref, nous n'avons pas les mêmes valeurs.
L'impression de grand fossé entre le monde des communicants et des organisants d'un côté et les codeurs de l'autre. Ce sentiment n'a rien de nouveau mais certains éléments anodins ne font rien pour arranger les choses. Je pense par exemple aux "personas" censées guider les gens vers les sessions faites pour les gens comme eux. Je pense à la 2ème keynote (oui, toujours la même) où est évoquée la classification des cultures d'un Michael Sahota qui, à mon avis, se trompe lourdement sur le Software Craftsmanship.

Les questions (que je me suis) posées

Que vaut la règle 5 ("One dot per line") des Object Calisthenics ? Surtout si l'on considère les DSL internes.
Est-ce qu'on est forcément con quand on est sceptique ou quand on résiste a un changement ?
Combien de développeurs continuent à souffrir sur du code de merde ?
Suite aux approches impératives et fonctionnelles du jeu de la vie vues dans le hands on Clojure, le langage C# n'est-il pas actuellement plus fonctionnel qu'impératif ?

Les lecons (re-)apprises

Remerciements

Au staff en rouge pour son implication tout au long de la journée. Je garderai cette image d'une salle de conf transformée quelques minutes en atelier pour le Clojure hands on.
Aux personnes rencontrées et avec qui j'ai pu discuter. Impossible de toutes les citer sans en oublier mais je remercie ici Michael, Charles et Jean-Baptiste sans qui je n'aurais pas autant apprécié mon séjour.

Ils en parlent aussi

Pour aller plus loin

Notes

[1] Bug ou pas bug, la valeur que retire l'utilisateur du produit est une mesure de la qualité

Agile Tour Toulouse 2012, entre câlinothérapie et WTFs

Oaz — Sun, 28 Oct 2012 18:49:00 +0100

Voici mon compte-rendu avec, parce que c'est Toulouse, un petit côté "rétrospective de l'organisation"

Ce qui était bien

La session plénière de début de journée. La pièce de théatre de Thierry et David fut un vrai régal. Quelqu'un a fait une video ?
Le bon accueil fait à ma présentation. J'étais un peu inquiet pour cette première de "Deux ans dans le flux" et le fait que je connaisse un nombre important de personnes dans l'assistance n'a rien fait pour arranger les choses. Je tiens particulièrement à remercier Géry Derbier pour la discussion qui a suivi^[1].
La compagnie de quelques sympathiques bordelais le temps du repas de midi (à noter que la fluidité dans la distribution des paniers repas n'avait rien de comparable avec la lenteur du buffet de l'an passé)
La "1ère année de Transition Agile à Air France". C'est le genre de présentation "l'agilité vue d'en haut" où l'on n'apprend pas grand chose pour son usage quotidien (à moins d'être un DSI ?) mais qui fait toujours plaisir à voir.
La session de cloture "Agile Unlimited" où Alexandre a bien marqué la différence entre "utiliser des pratiques que l'on rencontre dans l'agilité", ce que tout le monde peut faire facilement et "être agile", qui nécessite un changement culturel.
Les discussions qui ont continué pendant la soirée...

Ce qui était moins bien

L'adéquation des sessions aux salles en fonction de leur taille. Vu le nombre de personnes restant debout, j'ai préféré laisser ma place pour "Clean Code"^[2].
"L'agilité dans le référentiel Airbus". Globalement nul. J'aurais besoin d'un billet à part entière pour expliquer en détail le problème. Il faudrait que le comité de sélection soit plus vigilant à l'avenir.
"L'agilité : innovation utile au business !". Session inutile. Un contenu formellement juste mais loin de ce que pouvait laisser penser le titre. Ca ressemblait plutôt à une introduction à Scrum. J'ai l'impression que l'intervenant s'est contenté de recycler les slides qui lui servent pour présenter l'agilité à ses clients. J'ai quitté la salle en cours de route.
La non-sélection des sessions. 22 conférences retenues sans critères très pertinents (les ateliers sont un cas à part qui ne pose pas de problème)^[3]

Les questions (que je me suis) posées

Est-ce que je vis dans le pays de bisounours ? (comme me l'ont dit plusieurs auditeurs de ma présentation)
Si je vis vraiment dans le pays de bisounours, pourquoi les autres semblent-ils insatisfaits de l'endroit où ils vivent mais se contentent de chercher une méthode qui leur permette de faire avec ?
Pourquoi les gens disent "méthodologie" à la place de "méthode" ?
Le nombre de WTFs sur twitter est-il une bonne métrique de la qualité d'une présentation ?
Ne faudrait-il pas supprimer une ou deux salles de conférence ? 4 conférences en parallèle, c'est définitivement trop.
Ne faudrait-il pas mieux utiliser le grand amphi en sélectionnant et y programmant des sessions qui sortent du lot ?
Ne faudrait-il pas rajouter une 3ème piste d'ateliers ?
Ne faudrait-il pas dédier une salle aux "open talks" et, par exemple, initier le contenu quelques semaines avant, du genre "la salle dont vous faites le programme" ?

Les lecons (re-)apprises

La doc ça risque pas de planter ou de marcher
Si on veut être agile, on ne peut pas mettre la qualité de côté
Si on utilise le mot agile c'est que l'on est prêt à changer de culture

Remerciements

Merci à tous ceux qui ont rendu cette journée possible
Une mention spéciale aux étudiants de l'université Paul Sabatier qui se sont auto-organisés pour assurer l'accueil, la permanence et le time-tracking tout au long de la journée

Ils en parlent aussi

Pour aller plus loin

Notes

[1] et je viens de commander Agile Software Development d'Alistair Cockburn

[2] Après Bordeaux et Toulouse, il ne me reste que Montpellier pour (enfin) voir Jérôme

[3] NB : je fait partie des personnes qui ont "sélectionné"

Engagez-vous ils disaient...

Oaz — Mon, 15 Oct 2012 13:55:00 +0200

Air du temps ou coïncidence, je suis tombé sur deux billets traitant de l'engagement des développeurs :

Tout d'abord, dans le Bouzin Agile : Développeurs mettez vos couilles sur le billot.

L'engagement est la liste des Users Stories que l'équipe pense développer durant l'itération. [...] l'engagement permet quelque chose de très important à mes yeux : de placer la barre à une certaine hauteur et de comparer à la fin de l'itération ce qui a été réalisé

Et le jour suivant chez Coacher une équipe agile : Obtenir l’engagement de l’équipe.

on sait combien dans une démarche agile, la notion d’engagement sur le résultat du sprint est un élément-clé [...] Comment obtenez-vous l’engagement de tous les coéquipiers sur le nombre de story points ou le nombre de user stories, bref, sur le périmètre défini ?

J'ai un peu de mal à partager ces points de vue.

« L'engagement, c'est un mur conçu expressément pour que l'on fonce dedans. »

A vrai dire, je ne me suis jamais vraiment préoccupé de cette notion d'engagement. L'équipe dans laquelle je travaille a toujours plus ou moins eu un certain sens du travail à accomplir et des attentes de nos utilisateurs.
C'était vrai jusqu'à l'automne 2010 où une release s'est relativement mal passée. L'engagement était au coeur du malaise. Les développeurs, implicitement engagés, ont tenté vainement de livrer tout ce qui avait été, à leurs yeux, "promis", quitte à prendre quelques libertés avec les bonnes pratiques.

Alors on pourra toujours argumenter que l'équipe n'était pas prête à assumer cet engagement, qu'elle n'avait pas la maturité nécessaire pour concilier travail bien fait et engagement sur un périmètre. On pourra trouver toutes les raisons du monde pour dire que l'engagement c'est bien mais que, évidemment, il faut <insérer ici votre pratique favorite qu'il ne faut jamais abandonner>.
Tout ça pour quoi ?
Quel bénéfice réel tire-t-on d'une promesse sur un contenu sachant qu'il y a des pratiques plus prioritaires et non négociables ?

Pour ma part, je ne vois qu'un seul "avantage" : la possibilité de blâmer ceux qui n'ont pas tenu leur promesse.
Si on considère les trois variables coût-délai-contenu, on sait que lorsque deux d'entre elles sont fixées, la troisième ne peut qu'être mesurée ou espérée. Or, définir un engagement, c'est vouloir fixer, par des moyens détournés et avec une certaine bassesse, la variable contenu quand le coût et le délai sont déjà fixés.

Même l'argument "mais c'est pour le bien de l'équipe pour qu'elle réfléchisse à la façon de faire mieux" ne tient pas : soit on fait confiance aux gens pour qu'ils donnent le meilleur d'eux mêmes, soit on ne fait pas confiance.

« Le sage trouve mieux son compte à ne point s'engager qu'à vaincre. »

La petite mésaventure que je mentionnais un peu plus haut m'aura au moins permis de faire avancer une approche différente en me donnant l'occasion de supprimer les itérations pour aller vers un développement plus fluide.
Finies les itérations, finies les durées fixes, finis les engagements sur un contenu d'itération. L'équipe se focalise sur les deux ou trois éléments de backlog produit actifs à un instant donné et si un engagement lui est demandé, c'est de faire chaque jour de son mieux pour que ces éléments soient réalisés.

Mais, alors, me direz-vous, si l'équipe ne s'engage plus comment pourrais-je ~~leur mettre la pression à cette bande de bons à rien~~ savoir à quelle date telle ou telle fonctionnalité sera livrée au client ?
La planification, c'est à dire le fait de prédire quels élements seront réalisés ou pas pour une date donnée ne devrait pas être demandé aux développeurs. D'ailleurs, cela ne devrait être demandé à aucun être humain car aucun d'entre eux n'a les moyens de faire cette prédiction.
Chez nous, on a adopté une technique où on laisse une machine nous donner des probabilités de livraison en fonction des temps de réalisation observés sur les éléments passés^[1]. A l'usage, les prévisions que nous obtenons sont correctes (et même meilleures qu'en faisant intervenir des humains) tout en ayant fait baisser la pression inutile qui pèse sur les épaules d'une équipe que l'on pousserait trop à s'engager.

Ceux qui voudraient avoir un peu plus de détails sur ce qui a changé dans notre équipe du fait de cette transition méthodologique, je leur propose de venir le jeudi 25 octobre à Agile Tour Toulouse pour "Deux ans dans le flux"...

Notes

[1] la description détaillée de cette technique sera le sujet d'un billet ultérieur

Agile Tour Bordeaux 2012 : j'y étais

Oaz — Sat, 13 Oct 2012 21:24:00 +0200

Voici mon petit compte-rendu en "Agilarium-style".

Ce qui était bien

La keynote de Samir Hanna. Keynote n'est pas un synonyme pour "session plénière qui ouvre ou clôture". La keynote, comme son nom l'indique, c'est ce qui donne le ton pour ce qui va suivre et la courte introduction de la journée mettant en avant des valeurs était, en ce sens, la bienvenue.
What Testers and Developers Can Learn From Each Other par David Evans. Un véritable appel à la réconciliation des développeurs avec le test sous toutes ses formes et un orateur vraiment au dessus du lot.
Tests automatisés, le mythe du ROI par Gilles Mantel. Une taxonomie des tests très détaillée (peut-être un peu trop pour mon goût de la concision) mais surtout une modélisation du ROI des tests automatisés sur un principe d'option d'achat qu'il faut avoir vu avant d'émettre le moindre avis sur le sujet.
La voie du programmeur par Jean-Baptiste Dusseaut. Ma session préférée parce qu'elle aborde plein de thèmes qui me tiennent à coeur sur une question fondamentale : comment devient-on un professionnel du développement logiciel ? Elle devrait être imposée dans tous les agile tours de France et d'ailleurs.
Sociocratie: une gouvernance agile par Thierry Cros. J'ai encore du mal à voir comment cette idée disruptive peut prendre de l'ampleur dans le contexte actuel mais comment ne pas faire confiance à quelqu'un qui a senti la lame de fond du mouvement agile dès ses débuts ?
La soirée qui a suivi mais vous ne saurez rien : il fallait être là.

Ce qui était moins bien

La densité des sessions de l'après-midi. Quatre sessions en quatre heures, c'est un peu trop. Du coup, j'ai zappé le dernier créneau qui ne manquait pourtant pas d'interêt avec les sessions d'Isabel, Jérôme et Jonathan.
"Utilisateur mon amour ma migraine" par Sophie Freiermuth. De mon point de vue, la session fut à côté de la plaque sur l'aspect méthodes agiles. Des notions mal utilisées : quand on retravaille un existant, on fait de l'incrémental, pas de l'itératif ; une user story n'est jamais une spec détaillée, c'est au plus une invitation a discuter... Les plus gros travers restent cependant le BDUF omniprésent (le développeur est content quand on lui apporte une spec hyper détaillée et qu'il n'a pas à se poser trop de questions sur ce qu'il doit coder), la communication érigée en non-valeur ("le designer n'est pas intéresse par le code" - et donc il n'a aucune raison d'aller s'asseoir à côté du développeur) et l'hyper-spécialisation ("un développeur c'est quelqu'un qui résout des problèmes techniques" - qu'il ne se mêle pas de choses qui le dépassent !) Je suis pourtant convaincu qu'il y a une marge de progression énorme en User eXperience pour la plupart des produits logiciels mais il faut une approche qui colle avec un développement logiciel professionnel. A noter : je n'ai pas encore vu cette session de Sophie Freiermuth à Mix-IT qui, parait-il, était très bien.
Comme dans toutes les conférences de ce genre, il est impossible de voir toutes les sessions et j'ai donc surement raté des trucs intéressants.

Les questions (que je me suis) posées

Tests UX, tests exploratoires, tests de sérendipité ne sont-ils pas tous assimilables à des explorations au sens où même si on a une idée en tête, on ne sait pas vraiment où on va ?
Peut-on écréter la pyramide des tests de Mike Cohn ?
Y a-t-il des maîtres de l'artisanat logiciel et où sont-ils ?
Qui sera le premier à écrire un recueil de citations de Kent Beck ?
Peut-on être expert en développement logiciel à la sortie d'une école ? (nan j'déconne)
Les loldogs existent-ils ? (la réponse est oui)

Les lecons (re-)apprises

Une présentation devrait toujours commencer par un gag visuel
Ce n'est pas en rajoutant des tests que le logiciel devient de meilleure qualité
L'activité de test n'est jamais terminée, elle n'est qu'arrêtée
Les testeurs sont nos amis
Un ami, c'est celui qui aide a démenager un divan ; un meilleur ami, c'est celui qui aide a déplacer un corps...
Mettre en place des tests automatisés, c'est payer une prime limitée pour un gain potentiellement infini
Il faut nourrir sa passion
Le coding dojo, c'est comme le fight club : quand on y vient, il faut coder^[1]
Pas de commentaires dans le code

Remerciements

Merci aux organisateurs : Bastien, Florian, Samir, Jérôme, Mickaël et Guillaume.
Merci à toutes les personnes qui m'ont dit avoir apprécié ma session. C'était, comme d'habitude pour cet atelier, un peu le bazar par moments mais je pense que tous ceux qui se prennent au jeu en retirent forcément quelque chose - et moi aussi par la même occasion car, malgré le thème et les attentes imposées, c'est à chaque fois différent.
Et merci à tous les autres sans qui cet évènement n'aurait pas été ce qu'il a été.

Ils en parlent aussi

Pour aller plus loin

Notes

[1] dans le vrai fight club, cela n'est vrai que la première fois où l'on y vient - et de toutes façons on ne doit pas en parler

Agile Tour saison 5

Oaz — Sat, 29 Sep 2012 11:27:00 +0200

L'automne revient et la saison des agile tours recommence. Et cette année, le calendrier "sud-ouest" est plutôt sympathique puisque je vais pouvoir aller à Bordeaux, à Toulouse et à Montpellier dont les étapes sont suffisamment espacées dans le temps^[1].

Le 12 octobre, c'est la 4ème édition de l'agile tour Bordeaux. Il y a 7 bonnes raison d'y aller et en plus c'est GRATUIT (mais il faut s'inscrire).
Il y a même une 8ème raison : j'animerai une session "Si t'es pas SOLID, t'es pas agile", une sympathique expérience de programmation collective avec des composants logiciels humains qui montent sur scène pour découvrir ou re-découvrir le principe de substitution de Liskov, le principe d'inversion de dépendances et autres joyeusetés de la conception logicielle.
La session est la même que celle présentée à l'agile tour Toulouse l'an dernier, mais en mieux car elle a eu le temps d'être retravaillée et de mûrir.

Le 25 octobre, c'est la 5ème édition de l'agile tour Toulouse. Il faut toujours s'inscrire. Celui-là est payant mais le repas est inclus dans le prix.
J'y présenterai un retour d'expérience : Deux ans dans le flux. J'essaierai de raconter comment, depuis l'automne 2010, notre équipe a gagné en expérience et a modifié son approche du développement logiciel en s'aventurant sur des terrains qui peuvent sembler, a priori, éloignés des méthodes agiles.
Les orthodoxes de Scrum qui souhaiteraient assister à la session sont priés de laisser leurs oeillères au vestiaire.

Le 29 novembre, c'est la 2ème édition de l'agile tour Montpellier. Je ne sais pas s'il faut s'inscrire (pas trouvé l'info...) et je ne sais pas si j'y participerai en tant qu'orateur car le programme n'est pas encore connu (j'ai proposé les 2 sessions qui seront à Bordeaux et à Toulouse).

J'ai parcouru le programme de Bordeaux et celui de Toulouse.
Il y a quelques sessions que je ne veux pas manquer. Jean-Baptiste parlera de la voie du programmeur,un sujet que j'avais eu l'occasion d'approcher et qui est trop souvent marginalisé dans des conférences ~~scrum~~ agile. Il y a aussi Jérome avec Clean Code, un sujet technique primordial parmi la foule des sessions "TDD/BDD" ou "intégration continue".
Je crois aussi que, si l'occasion se présente, je me laisserai tenter par quelques sessions à la frontière des thèmes classiques de l'agilité. Je pense par exemple à "Utilisateur, mon amour, ma migraine".
En fonction de l'humeur du moment, il se pourrait aussi que j'aille jouer au troll dans une ou deux sessions (toulousaines) qui me semblent flirter avec l'arnaquagile...

Bref, de belles journées en perspective !

Notes

[1] il y a aussi une étape à Pau, voire à Marseille et Nice si on étend aux villes de agile Occitanie - dont Clermont-Ferrand ne fait étrangement pas partie

S'il y a un product owner, il peut y avoir un design owner

Oaz — Fri, 28 Sep 2012 12:35:00 +0200

Scrum, la méthode agile la plus populaire, définit un rôle de product owner. C'est un membre à part entière de l'équipe de développement qui a certaines responsabilités. Citons principalement :

décrire les éléments du backlog produit
les prioriser
approuver leur implémentation dans le produit

De manière anti-symétrique, la plupart des autres équipiers (oublions le scrummaster qui ne prend pas part directement à la création du produit), n'ont pas de rôle exclusif : ils sont pluridisciplinaires.

Il y a une possibilité pour régler ce problème de symétrie, c'est de dissoudre la responsabilité PO au sein de l'équipe en rendant chaque membre responsable des objectifs business et non plus seulement de la construction du produit. Les multiples approches du genre "PO proxy" ne sont, je pense, que des manières plus ou moins heureuses de tendre vers une telle organisation.

Il y a toutefois une autre façon pour redonner un peu de symétrie : tout comme il y a un product owner qui agit en tant que leader sur l'objectif business, il pourrait y avoir un design owner qui assurerait le leadership sur la conception du produit.
J'ai le sentiment (peut-être à tord ?) qu'une telle approche n'aurait pas bonne presse dans un contexte qui se définit comme agile.
En supprimant le command & control matérialisé la plupart du temps par un chef de projet omnipotent qui est avant tout un chef du planning et des ressources, la mouvance agile en est arrivée à promouvoir des organisations sans aucun chef.
J'ai l'impression (toujours peut-être à tord ?) qu'aujourd'hui il est difficile de faire valoir que certaines responsabilités de conception puissent être assignées à quelqu'un en particulier dont le choix serait prépondérant, tout comme le choix de priorisation d'un product owner est prépondérant sur celui des autres personnes qui peuvent concourir à l'objectif business.

Sans aller jusqu'à faire la promotion d'organisation de développement logiciel assez autocratiques comme pouvait le suggérer Brooks avec son chirurgien en chef dans le contexte des années 70, il me semble qu'une organisation peut introduire des rôles de leadership de conception tout en restant en accord avec les valeurs et les principes du manifeste agile.

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
Si cela est vrai en attribuant un rôle spécial à un unique product owner, alors cela reste vrai en attribuant un rôle spécial à un unique design owner.
Il ne s'agit pas de déposséder l'équipe de sa capacité d'autoorganisation. Tout équipier peut avoir son mot à dire sur tout ce qui concerne le produit. Un design owner dont les choix seraient contestés par la majorité des équipiers aurait un futur assez compromis. Cela n'est d'ailleurs pas moins vrai pour un product owner qui ferait des choix de priorités plus que douteux.

Le terme owner est d'ailleurs probablement mal choisi autant pour l'un que pour l'autre. Il s'agit plus de leaders qui donnent le cap et, par leur capacité à porter des décisions, assurent une certaine cohérence à l'ensemble.
Le fait est que dans la réalité des développements logiciels, ce rôle de design leader existe quasi-systématiquement de manière explicite ou implicite. Il existait même explicitement dans certaines méthodes agiles aujourd'hui oubliées^[1] à cause de la déferlante scrum.
Le monde de l'open source fourmille de dictateurs bienveillants qui sont un point positif pour la bonne marche de nombreux projets.
Plus généralement dans le monde de l'entreprise, qu'on le nomme Lead Programmer ou Tech Lead, ce responsable de la conception fait plutôt du bien à un projet de développement logiciel, du moins pour ce que j'ai pu en voir.

Son absence inconstestable dans la terminologie agile actuelle est pour moi un mystère.
Dans Software Craftsmanship: The New Imperative, Pete Mc Breen abordait l'organisation d'un projet de développement logiciel en parlant de Lead Software Craftsman. Le mouvement actuel du même nom (software craftsmanship), émanation de la mouvance agile, a repris bien des idées déjà présentes chez Mc Breen il y a 12 ans mais l'organisation avec hiérarchisation de rôles n'en fait étrangement pas partie.

Les agilistes sont-ils victimes d'un syndrome d'égalitarisme ?

Notes

[1] par exemple le team leader dans DSDM

La fausse bonne idée des Virtual Extension Methods dans Java 8

Oaz — Tue, 20 Mar 2012 08:08:00 +0100

Quand on s'intéresse aux évolutions de Java, il faut lire le Touilleur Express et plus particulièrement son compte rendu "Rémi Forax au Paris JUG". Apparemment, les lambda expressions feront leur apparition dans la version 8 du langage, ce dont tout le monde devrait se réjouir.
Je ne suis pas un habitué de Java. Mon premier langage fut le C++ et aujourd'hui celui que je maîtrise le mieux reste C# mais comment résister à l'envie de jeter un coup d'oeil aux évolutions de Java au moment où celui-ci se met à rattraper (un petit peu^[1]) son retard sur C# ?
Je vais essayer d'expliquer ce que j'ai compris et pourquoi je pense qu'un des choix effectués ne me semble pas être des plus judicieux^[2]

Un des principaux usages des lambdas expressions dans les langages orientés objet, c'est la manipulation de collections à travers quelques méthodes générales (filtrage, projection, aggregats, ...) paramétrées par des lambdas expressions.
C'est bien évidemment un des objectifs de l'introduction des lambdas dans Java comme l'explique Brian Goetz dans ces slides de novembre dernier : http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf

En pratique, le but est de pouvoir écrire le code suivant en Java :

List<Student> students = ...
double highestScore =
    students.filter(s -> s.getGradYear() == 2011)
                .map(s -> s.getScore())
                .reduce(0.0, Integer::max);

Cela n'est bien sûr que l'équivalent de ce que l'on peut écrire en C# depuis quelques années déjà :

List<Student> students = ...
double highestScore =
    students.Where(s => s.GradYear == 2011)
                .Select(s => s.Score)
                .Aggregate(0.0, Math.Max);

Une question annexe est alors : comment définir les méthodes filter/map/reduce sur une collection ?
C# a fait un choix simple. Where/Select/Aggregate et bon nombre d'autres opérations sont définies comme méthodes d'extension statiques. Ce sont tout simplement des méthodes statiques d'une classe statique qu'un artifice du compilateur permet de faire apparaitre comme des méthodes de toute énumération.
Dans la suite de ce billet je les appelerai SEM (pour Static Extension Method)

Pour le compilateur C#, le code précédent est strictement équivalent à celui-ci :

double highestScore =
  Enumerable.Aggregate (
    Enumerable.Select (
      Enumerable.Where (students, s => s.GradYear == 2011),
      s => s.Score
    ),
    0.0, Math.Max
  );

Visiblement, cette façon de faire ne plait pas aux concepteurs de Java. Brian Goetz détaille les objections suivantes :

Classes don’t know about their extension methods so cannot provide a “better” implementation
Not reflectively discoverable
No covariant overrides
Brittle – if default changes, clients have to be recompiled
Poor interaction with existing instance methods of same name
Not very object-oriented

Voyons un peu ce qu'il en est vraiment.

Les classes ne connaissent pas leurs méthodes d'extension. C'est en partie vrai (seule l'interface IQueryable permet de faire varier l'implémentation des SEM, c'est d'ailleurs le fondement de LINQ) mais dans la plupart des cas, on n'en a rien à faire. Les SEM ne sont pas là pour étendre une abstraction, elles sont là pour proposer un concept d'implémentation indépendant du type auquel elles se rapportent.^[3]
Etant indépendantes des types, les SEM ne sont pas accessibles à travers la réflexion. C'est vrai mais à quoi cela pourrait servir ? Quand on se soucie de réflexion sur les méthodes d'un type, c'est que l'on aurait grand besoin, au choix, de revoir sa conception^[4] ou d'aller vers un langage plus dynamique.
Je ne m'étendrai pas sur les redéfinitions covariantes qui n'existent pas en C# et auxquelles je préfère une conception à base de types paramétrés
La prétendue "fragilité" due au manque de compatibilité binaire est un leurre. La compatibilité source est la seule qui a de l'importance à mes yeux pour définir (il faudra souvent le rappeler) des concepts d'implémentation
L'existence de méthodes du même nom que les extensions est sans objet : qui aurait intérêt à définir ce genre de doublons ?
Le "not very object-oriented", c'est le "cherry on top". Est-ce que les lambdas expressions sont "very object-oriented" ???

Vous l'aurez compris : je ne partage pas vraiment le point de vue de ces javaistes sur les extension methods de C#.
Mais voyons un peu ce qu'ils proposent pour faire mieux. Ils appelent ça les "Virtual Extension Methods". Cela consiste à fournir une implémentation par défaut à une méthode d'une interface.

Exemple :

interface List<T> {
  // existing methods, plus
  void sort(Comparator<? super T> cmp) default { Collections.sort(this, cmp); };
}

A première vue, je me suis dit "pourquoi pas ?".
Cela fournit un mécanisme élégant pour faire des héritages de comportement et si ça permet de combler les défauts mineurs de l'extension par méthode statique, il n'y a pas de raison de s'en passer.
Mais j'ai quand même un peu réfléchi à la question et il y a quelques raisons qui me font penser que l'approche choisie par C# est bien meilleure.

Raison No 1 : l'extension de types existants

Imaginons que, dans notre exemple de code, nous ayons envie de simplifier l'écriture de la manière suivante :

List<Student> students = ...
double highestScore =
    students.Where(s => s.GradYear == 2011)
                .Select(s => s.Score)
                .Max();

En effet, le "Aggregate(0.0, Math.Max)" n'est pas un modèle de lisibilité et il gagnerait à être raccourci par le rajout d'une méthode qui renvoie le maximum d'une collection.

En C#, cette fonction "Max" existe nativement mais, si elle n'existait pas, elle serait très facile à rajouter avec une SEM car celles-ci sont entièrement indépendantes des types auxquelles elles se rapportent :

static class MyIEnumerableExtension {
  static double Max(this IEnumerable<double> self)
  {
     return self.Aggregate(0.0, Math.Max);
  }
}

Allez donc faire ça avec les VEM de Java sans toucher à l'interface...
C'est d'ailleurs dingue ce que l'on peut faire dès que l'on a la possibilité de rajouter des méthodes à une interface sans toucher à celle-ci.
La future version de java aura de nouvelles méthodes filter/map/reduce dans ses collections mais comment être exhaustif et ne pas oublier toutes les méthodes qui pourraient être utiles ?
J'espère que ceux qui amélioreront les interfaces auront une bonne boule de cristal... Ils ne faudrait pas qu'ils oublient de mettre des méthodes de groupement et de mise en dictionnaire. Elles sont parfois si utiles.

List<Student> students = ...
Dictionary<double,IEnumerable<Student>> studentsByScore =
  students.GroupBy (s => s.Score)
          .ToDictionary (g => g.Key, g => g.AsEnumerable());

Raison No 2 : la maintenabilité au delà de la réutilisabilité

L'aspect le plus élégant des VEM (mixer du code et des interfaces) est aussi le plus dangereux en termes de maintenabilité.
Commençons par rappeler quelques principes énoncés par Uncle Bob :

Common Closure Principle
The classes in a package should be closed together against the same kind of changes.
A change that affects a package affects all the classes in that package.

Stable Abstractions Principle
Packages that are maximally stable should be maximally abstract.
Instable packages should be concrete.
The abstraction of a package should be in proportion to its stability.

Si l'on admet que le respect de ces principes (et de quelques autres) maximise la maintenabilité d'une application, alors on a un petit problème avec les VEM.
Mélanger une abstraction relativement stable avec un détail d'implémentation qui va plus souvent évoluer, fut-il un comportement par défaut, ne va pas dans le sens de regroupements maintenables.

En clair, on est dans un des deux contextes suivants :

Soit les VEM ne sont utilisées qu'à la marge et on n'a pas de problème de maintenabilité. On peut alors se demander si les VEM sont une véritable stratégie du langage Java ou une simple réponse tactique au seul problème de la compatibilité des collections Java existantes avec le rajout filter/map/reduce...
Soit les VEM sont amplement utilisées et elles sont alors une improbable invitation à mélanger abstraction stables et détails d'implémentation anéantissant ainsi tout effort allant vers plus de maintenabilité d'une application Java

A l'inverse, les SEM de C# induisent une séparation claire entre les abstractions et les implémentations.

Raison No 3 : une fonctionnalité pour les développeurs d'applications

Cette troisième raison est un peu le corollaire des deux raisons précédentes.
Brian Goetz écrit :

The whole point of extension methods is being able to compatibly evolve APIs
The key operation we care about is adding new methods with defaults to existing interfaces without necessarily recompiling the implementation class

Les solutions qu'il apporte vont clairement dans le sens de la facilitation d'écriture de librairie tierces et d'API : les Virtual Extension Methods de Java ne sont qu'une fonctionnalité pour les développeurs de composants et de frameworks
A l'inverse, avec leurs possibilités d'extension de types externes et de séparation abstraction/détail, les Static Extension Methods de C# sont une fonctionnalité pour les développeurs d'applications.

On pourra argumenter que c'est important d'avoir des composant tiers extensibles qui ne cassent pas la compatibilité binaire et qu'à ce titre, les VEM sont un bon choix.
A cela, je suis tenté de répondre :

que l'extensibilité grace aux VEM est plus que relative (on ne peut pas rajouter une méthode à une interface sans casser la compatibilité binaire...)
que le mécanisme IQueryable de C#/.NET qui est un des fondements de LINQ offre des possibilités bien supérieures si on tient absolument à écrire des composants binairement indépendants avec des fonctionnalités d'un tout autre ordre (récupération dynamique de l'arbre d'expression sous-jacent aux appels extension methods + lambdas)^[5]

Ma conclusion est simple : le choix VEM vs SEM est un peu le reflet de l'écosystème dans lequel chacun des langages évolue.
En tant que développeur d'applications, je suis bien content d'utiliser C# et ses extensions statiques qui facilitent ma vie de tous les jours. Je laisse volontiers les Virtual Extension Methods aux amoureux des frameworks en tout genre et aux adeptes des armées de librairies à tout faire et à assembler "comme on peut"...

Notes

[1] troll inside

[2] Et si je fais des erreurs dans ce billet, je ne doute pas qu'un javaiste de passage saura me le faire remarquer...

[3] J'ai écrit récemment une série de billets sur le sujet. Le premier est là.

[4] Il y aurait un billet entier à faire sur "comment se passer de la réflexion sur les méthodes"

[5] Il faudrait là aussi un billet complet pour montrer le polymorphisme introduit en C# par LINQ

Les logiciels petits sont les plus jolis

Oaz — Fri, 09 Mar 2012 08:08:00 +0100

Cinquième billet et dernier billet de cette série sur la conception de logiciels^[1]
Que se passe-t-il lorsqu'un logiciel grossit ?
Est-on en mesure d'introduire indéfiniment de nouveaux concepts et de conserver un ensemble toujours aussi évolutif ?

Je ne crois pas que cela soit possible car

cela nécessiterait une équipe de plus en plus grosse pour gérer la base de code
et cela demanderait un effort monumental pour garantir la cohérence fonctionnelle de l'ensemble

Je sais que, dans certains endroits, plusieurs équipes travaillent simultanément sur la même base de code, chaque équipe étant en charge de fonctionnalités bien définies. On parle alors d'"équipe feature"^[2]. Je n'ai jamais expérimenté cela et je reste dubitatif sur l'efficacité de la chose.
Il m'est arrivé de travailler sur de gros logiciels mais le développement de ceux-ci était toujours organisé en composants, chaque composant ayant sa base de code propre et son équipe dédiée, y compris au niveau fonctionnel : un chef de produit et un backlog produit par composant.

La plus grande qualité que je trouve aux composants logiciels, c'est qu'ils permettent à la base de code d'un logiciel de rester dans une taille raisonnable. Cela se réalise en considérant chaque composant comme un logiciel à part entière avec ses propres exigences et ses propres concepts.
A mon avis, le seul risque de cette approche est de définir des composants trop en amont dans le développement d'un logiciel, ce qui pourrait amener à des choix qui se marient mal avec les concepts du logiciel décomposé.
Mais si on laisse faire les choses et que l'on découpe au moment opportun, le risque disparait.

Exemple :

1- Le code d'un logiciel a été simplifié grace à un concept d'implémentation
2- Après quelques évolution du logiciel, le concept sous-jacent commence à grossir
3- Il grossit tellement qu'il commence lui-même à être organisé avec des abstractions et des détails
4- Il devient alors un produit logiciel à part entière où une partie de ses concepts d'architecture sont l'API qui permet de l'utiliser
5- Notre logiciel est revenu à sa taille initiale (voire à une taille plus petite) car il utilise un produit tiers qui a son propre cycle de vie

Autre exemple :

1- Un gros logiciel est défini par ses concepts d'architecture et ses détails d'implémentation
2- Une partie de ce logiciel est fortement découplée du reste (le lien ne se fait que par quelques abstractions) : elle est naturellement organisée comme si elle était un produit à part entière, les quelques abstraction formant le lien étant l'API du produit distinct
3- On donne sa liberté à ce produit et le logiciel initial retourne une taille raisonnable tout en ayant limité le lien avec le nouveau produit tiers à un seul de ses détails d'implémentation

On voit donc que l'émergence de produits tiers à partir de morceaux d'un logiciel existant peut être intéressante si elle respecte le découpage naturel du logiciel, c'est à dire si elle se base sur des concepts qui ont déjà émergé. Par ailleurs, comme nos jeux de tests se basent sur les concepts, qu'ils soient d'architecture ou d'implémentation, les nouveaux produits débutent leur existence avec des jeux de tests qui expriment clairement leur comportement.

Il existe toutefois des cas où les choses ne sont pas aussi simples.

1- Prenons un logiciel qui, à travers ses concepts d'architecture, propose une API et la possibilité d'être étendu par divers détails présentés comme des "plugins"
2- Si ces plugins venaient à grossir, on ne pourrait pas les considérer comme des produits tiers dont dépend le logiciel car l'API fait partie du logiciel et les plugins en dépendent. Une solution est alors de considérer notre le logiciel initial comme un produit tiers.
3- En faisant cela, les plugins deviennent notre logiciel principal qui va pouvoir grossir en dépendant du produit tiers nouvellement créé. Cette opération est toutefois délicate car l'API qui sert désormais de point d'entrée au produit tiers n'est pas forcément adaptée à cela et, du fait de l'orientation "plugins", elle ne possède peut être pas les jeux de tests adéquats.

Cela reste une exemple. On pourrait avoir un plugin qui grossirait par introduction d'un concept d'implémentation lequel deviendrait à son tour un produit à part entière (cf 1er exemple du billet).
On retiendra que le concept d'architecture de type "API qui permet d'étendre un logiciel", ça peut être sympa sur le moment mais ça peut engendrer des inconvénients à plus long terme en fonction de la façon dont on appréhende le développement des plugins.

Voilà...
Ainsi s'achève cette série sur la conception de logiciels, ou devrais-je plutôt dire sur ma vision, en ce début d'année 2012, de ce qui me semble primordial dans la réalisation d'un logiciel. J'espère que cela aura intéressé quelques personnes. J'espère aussi avoir quelques retours qu'ils soient positifs ou négatifs. En tout cas, cela aura bien occupé mon temps libre de la semaine !

Notes

[1] Les quatre premiers billets sont là : Conception logicielle ; Le logiciel, un organisme multicellulaire ? ; Chacun cherche son TDD ; Le logiciel d'un développeur est son château.

[2] L'article "Feature Team Primer" dont une traduction par Fabrice Aimetti est disponible ici : http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/06/13/Equipe-feature présente ce genre d'organisation mais, pour moi, les auteurs avancent des arguments qui reposent entièrement sur une définition que je ne partage pas de ce qu'est une "architecture". Il faudrait un billet complet pour détailler ce sujet...

Le logiciel d'un développeur est son château

Oaz — Thu, 08 Mar 2012 08:08:00 +0100

Quatrième billet de la série sur la conception de logiciels^[1]

Je n'ai pas encore abordé la question des éléments tiers dans la réalisation d'un logiciel.
Il y a une bonne raison à cela : je crois fermement que c'est un point de détail qui ne mérite pas une place trop importante.

Quand on discute sur les méthodes agiles et sur la capacité de pouvoir remettre en cause à tout moment le comportement de l'existant pour satisfaire au besoin le plus prioritaire d'un produit logiciel, il y a toujours quelqu'un pour dire "Oui on peut faire des changements mais il y a quand même des choix d'architecture que l'on ne peut pas facilement modifier". Et bien souvent il y a quelqu'un pour rajouter "c'est pourquoi il faut définir l'architecture dans la première itération". Il m'est arrivé plusieurs fois d'entendre cela et je ne partage pas du tout cet avis.

Cette divergence de points de vue est simple à comprendre : tout le monde ne met pas la même chose derrière le mot "architecture".

Choisir un SGBDR X ou Y ou choisir un stockage "NoSQL", ce n'est pas faire un choix d'architecture, c'est faire le choix des détails d'un mécanisme de persistance.
Choisir un framework web Y ou Z, ce n'est pas faire un choix d'architecture, c'est faire le choix des détails d'un mécanisme de diffusion de données.

Comme le dit l'académie française^[2], l'architecture, c'est la disposition, l'ordonnance d'un édifice. Les choix d'architecture doivent représenter ce qui est fondamental -et rien d'autre- dans un logiciel, ce qui constitue sa nature, des choses telles que la modélisation du domaine métier ou la formalisation des principales opérations réalisées par le logiciel.
Cette approche permet de garantir un point essentiel de l'architecture : sa stabilité. Sous certaines conditions, cette stabilité ne remet pas en cause la capacité à modifier un comportement et elle offre la possibilité de changer de mécanisme de persistance ou de diffusion à tout moment dans la (longue) vie du logiciel.

Une des conditions est que les concepts d'architecture ne doivent pas dépendre de logiciels tiers. Bien evidemment la suppression de toutes les dépendances est impossible : si les concepts d'architecture sont exprimés dans un langage informatique, ils dépendent, au minimum, de la syntaxe de ce langage et d'un interpréteur/compilateur/runtime associé. Idéalement, il ne devrait y avoir aucune autre dépendance.

En résumé, un logiciel est à son développeur ce que sa maison est à un anglais : son château, c'est à dire un endroit où il n'a pas à subir les invasions de logiciels tiers et de leurs hordes de contraintes.

Si tout cela est acquis, seuls les concepts et les détails d'implémentation dépendent des logiciels tiers (représentés en vert dans le schema qui suit).
La dépendance à un tiers donné se limite alors à un élément précis et ne s'éparpille pas dans tous les détails du logiciel. Les concepts d'implémentation peuvent centraliser ces dépendances le cas échéant.

Voilà réglée de manière un peu radicale la question des tiers.
Il va sans dire que certaines pratiques désormais courantes, telles que prendre un framework tiers pour constituer l'ossature d'un logiciel, me font hurler...

Le prochain billet abordera un sujet connexe : le cas des GROS logiciels et de leur possible décomposition...

Notes

[1] Les trois premiers billets sont là : Conception logicielle ; Le logiciel, un organisme multicellulaire ? et Chacun cherche son TDD.

[2] cf premier billet de la série : Conception logicielle

Chacun cherche son TDD

Oaz — Wed, 07 Mar 2012 08:08:00 +0100

Ce billet est le troisième d'une série sur la conception de logiciels^[1].

Après avoir parlé de l'évolution d'un logiciel et de l'émergence des divers concepts qui le composent, voyons comment un développeur peut maitriser cette évolution. Le meilleur outil que je connaisse aujourd'hui pour cela, c'est le développement piloté par les tests^[2].

Beaucoup de choses ont été écrites sur le TDD et ce billet sera donc un énième point de vue (le mien) sur le sujet.
Des reproches lui sont régulièrement faits : "le nombre de tests à écrire est trop coûteux", "le TDD est une mauvaise approche car il est inutile de tester toutes les fonctions/toutes les méthodes de toutes les classes", ...
Ces points de vue me donnent au moins une certitude : tout le monde ne met pas la même chose derrière le mot TDD.

En ce qui me concerne, le TDD me sert à deux choses :

1- faire émerger et peaufiner les concepts d'un logiciel, aussi bien ceux d'architecture que d'implémentation
2- vérifier le comportement des détails d'implémentation au travers des concepts

Le premier point est la conséquence directe de l'évolution naturelle d'un logiciel par conception émergente.
Regardons comment peuvent apparaitre des concepts d'architecture lors d'un pilotage par les tests.

1- On a un test vide ;
2- On commence à écrire le test : un début de concept apparait pour accéder aux détails à venir ;
3- Les détails apparaissent. On passe alors par plusieurs phase red-green-refactor qui vont faire évoluer à la fois l'implémentation et le concept pour arriver à un résultat satisfaisant ;
4- On introduit d'autres scénarios de test. Lors des red-green-refactor, d'autres concepts apparaissent ;
5- Les concepts ont permis de diviser les détails. Une partie peut alors être avantageusement remplacée par une doublure pour favoriser la croissance ultérieure du logiciel.

L'apparition de nouveaux concepts d'architecture est le cas de figure idéal pour découpler les détails d'implémentation mais elle n'est jamais garantie.
Quand des détails deviennent trop complexes, il reste la possibilité d'introduire de nouveaux concepts d'implémentation comme dans l'exemple suivant.

1- On a un test vide ;
2- On commence à écrire le test : un début de concept apparait pour accéder aux détails à venir ;
3- Les détails apparaissent. On passe alors par plusieurs phase red-green-refactor qui vont faire évoluer à la fois l'implémentation et le concept pour arriver à un résultat satisfaisant ;
4- On introduit d'autres scénarios de test. Lors des red-green-refactor, le code se complexifie ;
5- On travaille sur un nouveau concept d'implémentation pour simplifier le code. Pour cela, on rajoute des tests ad-hoc et on fait évoluer en parallèle le nouveau concept et son utilisation ;
6- Le nouveau concept finit par remplacer complètement le code trop complexe.

Le point délicat de ces phases d'émergence est que, bien évidemment, les tests existants portent sur des concepts existants. Toute la difficulté réside dans la création de jeux de tests portant sur les nouveaux concepts. Cela nécessite soit de mener en parallèle l'émergence et la constitution des nouveaux tests, soit de les écrire a posteriori.
En l'occurrence, dans le premier exemple on n'a pas introduit de scenarios de tests utilisant le dernier concept créé pour vérifier les détails qui ont été séparés. Cela doit être fait immédiatement après pour permettre à ces détails de continuer à croitre sereinement.

Une caractéristique commune à tous les tests de ces exemples est qu'ils ne dépendent que des concepts, jamais des détails.
Pour moi, c'est un point important. Les tests sont écrits en utilisant des notions stables. Cela permet à la fois d'écrire des tests qui résisteront mieux à l'épreuve du temps et de les exprimer avec un vocabulaire clairement défini. Un test, ce n'est pas juste du code qui affiche une bande verte ou une bande rouge, c'est surtout un moyen de décrire intelligiblement le comportement du logiciel.

A l'usage, la manière d'écrire les tests diffère sensiblement selon que l'on manipule des concepts d'architecture ou des concepts d'implémentation.
Les concepts d'implémentation sont très proches des détails du code. Je trouve que les outils de type xUnit^[3] se prêtent bien à l'écriture des tests qui y sont rattachés. Ils permettent de construire des concepts qui utilisent un maximum de possibilités du langage utilisé (par exemple, pour des fluent interfaces^[4])

Les concepts d'architecture constituent le langage commun aux divers éléments d'un logiciel et, par extension, aux personnes qui participent au développement de ce logiciel. C'est en utilisant ce langage que l'on peut écrire des spécifications exécutables. Les concepts peuvent ainsi être paramétrés dans des outils de spécification exécutables de type 'scenario' (cucumber, specflow, jbehave...)
Typiquement, on pourra créer une bibliothèque de doublures dont les étapes d'initialisation seront utilisées dans les pré-conditions d'un scenario. On peut ainsi se constituer un "DSL" de spécifications pour notre logiciel. En se basant uniquement sur les concepts d'architecture, on peut écrire tous les scénarios utiles dans un langage naturel sans avoir à systématiquement détailler les étapes dans du code spécifique.
J'ai trop peu d'expérience avec les outils de spécification de type 'document' (fitnesse, concordion...) mais je suppose que l'on peut les utiliser de la même manière.

Emergence de la conception... Pilotage par les tests... Tout cela marche souvent très bien quand on écrit du code qui fonctionne en autarcie. Les choses peuvent être légèrement différentes quand il s'agit d'interagir avec des logiciels tiers
Dans le prochain billet, j'essaierai donc de parler des relations qu'un logiciel entretient avec son environnement.

Notes

[1] Les deux premiers billets sont là : Conception logicielle et Le logiciel, un organisme multicellulaire ?

[2] http://fr.wikipedia.org/wiki/Test_Driven_Development

[3] http://en.wikipedia.org/wiki/XUnit

[4] http://en.wikipedia.org/wiki/Fluent_interface

Le logiciel, un organisme multicellulaire ?

Oaz — Tue, 06 Mar 2012 08:08:00 +0100

Ce billet est le deuxième d'une série sur le conception de logiciels^[1].

Je m'intéresse aujourd'hui à la manière dont évolue la structure d'un logiciel, notamment en ce qui concerne les concepts dont on a pu parler précédemment.

Il y a fort longtemps, les cours que j'ai pu avoir en relation avec le développement logiciel avaient toujours une approche assez constructiviste : avant d'écrire la moindre ligne de code, on commence par découper un problème donné en problèmes élémentaires, puis on réfléchit aux concepts que l'on va utiliser, ensuite on commence a écrire des bouts de code que l'on va assembler pour parvenir au logiciel final.

En suivant cette démarche, on commence par définir l'architecture du logiciel avant d'en réaliser les détails :

Et même au niveau des détails, on est amené à suivre la même approche. On commence par implémenter quelques concepts de base avant de les assembler :

Cette approche a le mérite d'être analogue à certains domaines de l'ingénierie ("on crée le plan avant de réaliser l'ouvrage") mais, en ce qui me concerne, elle survit difficilement à la réalité du développement logiciel.
Je n'ai jamais vu quelqu'un bâtir intégralement un logiciel comme on construirait une maison. A un moment ou à un autre, le logiciel dévie sensiblement du moindre plan que l'on aurait pu faire. En fait, par certains aspects, un logiciel ressemble à un organisme...

Organisme : entité biologique, unicellulaire ou pluricellulaire, capable de se développer et de se reproduire.

Dans le phénomène probablement le plus connu de la reproduction cellulaire, la mitose^[2], une cellule croit et se divise pour au final donner deux cellules génétiquement identiques mais qui peuvent être fonctionnellement différenciées.

Il en va un peu de même pour la formation des concepts d'architecture d'un logiciel. Lorsqu'une implémentation grossit, des abstractions apparaissent et, si tout se passe bien, l'implémentation se divise en deux parties indépendantes mais rattachées par ces nouvelles abstractions.

Pour rester dans le même type d'analogie, on pourrait aussi évoquer la réparation d'une plaie cutanée^[3] : l'organisme s'auto-répare lorsque survient une blessure légère.

Dans un logiciel, le code blessé est celui qui, devenu trop complexe, ne peut plus évoluer correctement. L'émergence de concepts d'implémentation répare le code et lui permet d'aller de l'avant.

Bref, même si de bons concepts peuvent être pensés a priori, il ne faut pas abuser de la chose. Un logiciel qui évolue harmonieusement à partir de besoins de conceptualisation avérés (une abstraction qui émerge, une implémentation qui se simplifie) a de meilleures chances d'évoluer et croitre qu'une créature de Frankenstein assemblée à partir de morceaux choisis en amont.

Le défi dans l'évolution d'un logiciel, c'est la manière dont un développeur arrive à la contrôler. Cela sera le sujet d'un prochain billet.

Notes

[1] Le premier billet est là : Conception logicielle

[2] http://fr.wikipedia.org/wiki/Mitose

[3] http://www.chups.jussieu.fr/polys/histo/histoP2/POLY.Chp.5.6.html

Conception logicielle

Oaz — Mon, 05 Mar 2012 08:08:00 +0100

Une pratique utile à tout développeur de logiciels est l'analyse de son propre travail^[1]. C'est dans cet esprit que j'entame aujourd'hui une petite série de billets sur la conception de logiciels, ou, plus précisément, ce qu'est, à cet instant, pour moi, la conception de logiciels.
C'est à la fois une façon de faire un point personnel sur ce que j'ai appris^[2], de le partager avec tous ceux qui pourraient être intéressés^[3], et enfin de l'exposer à la critique publique de ceux qui prendront le temps de le lire^[4].
Dans cette série de billets, je compte donc aborder les points qui me paraissent les plus importants dans la conception, la manière dont ils évoluent au fil du temps, le contrôle qu'exerce un développeur sur cette évolution et les relations qu'entretient le logiciel avec son environnement.

Avant de parler de "conception" logicielle, il me faut définir le terme.
Le dictionnaire de l'académie française^[5] propose plusieurs définition pour la conception. Celle-ci me parait adaptée.

Conception : Action de former le concept d'un objet

Allons voir la définition d'un concept. Il y en a, là aussi, plusieurs mais je prends celle qui me convient le mieux :

Concept : Construction de l'esprit explicitant un ensemble stable de caractères communs désigné par un signe verbal.

Ainsi, j'ai envie de dire que concevoir un logiciel, c'est nommer et décrire ce que partagent les divers éléments qui le composent. Ce partage induit une dépendance des divers éléments, les détails, envers ce qu'ils ont en commun.

Ceci étant, tous les concepts n'ont pas la même nature. J'en distingue deux :

Certains concepts sont omniprésent sur l'ensemble du logiciel. Ils permettent de décrire, par exemple, le domaine métier que le logiciel manipule^[6] ou encore les contrats que respectent les divers éléments quand ils dialoguent les uns avec les autres^[7].
D'autres concepts n'ont de raison d'être que par rapport à une tactique de réalisation du logiciel. Un élément va, par exemple, utiliser une évaluation paresseuse^[8] pour optimiser les performances ; d'autres élements aux algorithmes similaires vont partager un patron de méthode^[9] ; etc.

Intéressons-nous au premier cas. Les concepts omniprésents sont la base sans laquelle le logiciel ne pourrait exister. Ils décrivent la manière dont les élements de détail sont agencés les uns par rapport aux autres. Il y a un mot qui me rappelle cette idée de mise en forme globale d'une construction :

Architecture : Disposition, ordonnance d'un édifice.

On pourrait donc parler de concepts d'architecture.

Faisons un zoom sur le schema précédent pour apercevoir les packages qui composent le logiciel. On entend ici par package des bouts de code dont le contenu est lié par un destin commun, tant du point de vue de l'utilisation que de la modification^[10]. On a, en bleu, les packages contenant les concepts d'architecture et, en rouge, les détails de réalisation du logiciel.

Faisons un aparté rapide pour préciser que l'association implicite "concept <-> bouts de code" n'a rien d'étonnant. On peut dessiner un concept sur un tableau ; on peut le décrire dans un document mais s'il n'est pas présent explicitement dans le code, il n'existe pas !

Si on fait un nouveau zoom, on découvre les concepts d'implémentation qui constituent les choix de construction des détails. A priori, ces concepts sont internes aux packages de détails car l'utilisation d'un entre eux dans un package n'a aucune implication sur les autres packages. Sur le schéma suivant, les concepts d'implémentation sont représentés en beige.

Toutefois, il arrive que certains de ces concepts soient utilisés dans plusieurs situations indépendantes. Ils intègrent alors, pour des raisons pratiques, des packages partagés.

On se retrouve ainsi avec plusieurs niveaux de définition d'un logiciel sur lesquels on doit pouvoir vérifier les progressions habituelles d'abstraction et de stabilité^[11].

	Concepts d'architecture	Concepts d'implémentation	Détails d'implémentation
Dépendances	Ne dépendent que d'autres concepts d'architecture	Peuvent dépendre de concepts d'architecture ou de d'autres concepts d'implémentation	Dépendent de concepts d'architecture et de concepts d'implémentation
Niveau d'abstraction	Entièrement abstraits	Mélange d'abstraction et de détails	Entièrement composés de détails
Niveau de stabilité	Stabilité maximale	Partiellement stable	Change au moindre changement dans le logiciel

Dans un prochain billet, on parlera de la formation et de l'évolution de ces divers éléments.

Notes

[1] Apprenticeship Patterns "Reflect as you work" - http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#reflect_as_you_work

[2] Apprenticeship Patterns "Record what you learn" - http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#record_what_you_learn

[3] Apprenticeship Patterns "Share what you learn" - http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#share_what_you_learn

[4] Apprenticeship Patterns "Create feedback loops" - http://ofps.oreilly.com/titles/9780596518387/perpetual_learning.html#create_feedback_loops

[5] http://www.academie-francaise.fr/dictionnaire/

[6] http://en.wikipedia.org/wiki/Domain_model

[7] http://en.wikipedia.org/wiki/Interface_%28computing%29

[8] http://en.wikipedia.org/wiki/Lazy_evaluation

[9] http://en.wikipedia.org/wiki/Template_method_pattern

[10] http://www.objectmentor.com/resources/articles/granularity.pdf

[11] http://www.objectmentor.com/resources/articles/stability.pdf

Je n'aime pas les conteneurs d'injection de dépendances

Oaz — Wed, 15 Feb 2012 01:08:00 +0100

Je n'ai rien contre les DI containers en tant que tels. Je pratique l'injection de dépendances aussi souvent que nécessaire mais j'ai un problème avec les librairies et frameworks en tout genre qui me donnent plus de complications à gérer que d'écrire le code correspondant aux 10% de fonctionnalités dont j'ai réellement besoin.

C'est pour cela que je lis avec grand plaisir des phrases telles que "Dependency Injection doesn’t require a framework; it just requires that you invert your dependencies and then construct and pass your arguments to deeper layers" venant de quelqu'un dont la crédibilité n'est plus à démontrer.

L'injection de dépendances, ce n'est jamais qu'un cas particulier de l'inversion de dépendances, c'est à dire d'une structuration logicielle où les détails d'implémentation ne dépendent pas l'un de l'autre mais dépendent tous d'abstractions.
La spécificité de l'injection de dépendances, c'est, étant donnés un contexte et une abstraction, d'être capable de fournir automatiquement le détail d'implémentation de l'abstraction pour le contexte considéré. Bref, si on est capable d'implémenter l'appel suivant (écrit dans un pseudo langage objet), on est sur la bonne voie :

instance = context.GetDetailsFor(abstraction)

Une abstraction, c'est typiquement ce que, dans les langages orientés objets les plus courants, on appelle une "interface", Mais un contexte ? J'ai un théorème pour répondre à ça.

Théorème de oaz sur l'injection de dépendance

Le contexte d'une injection de dépendance peut se limiter à un choix de package

Démonstration

Une abstraction étant fixée, une injection de dépendance est le choix d'une classe implémentant cette abstraction et des arguments de construction d'une instance de cette classe.
Les arguments de constructions peuvent être rendus optionnels : il suffit pour cela d'utiliser une classe dérivée ad hoc où les arguments en question sont fixés.
Reste à choisir la classe à instancier.
Si une injection de dépendance nécessitait plus qu'un choix de package, cela signifierait que, en plus du package choisi, il faut d'autres informations qui permettent de choisir telle ou telle classe du package implémentant l'abstraction considérée. Cela implique que, parmi les classes du package choisi, au moins deux d'entre elles implémentent la même abstraction injectable et et ces deux ne vont donc pas être utilisées simultanément.
L'existence de ces deux classes dans le même package est une violation du Common Reuse Principle qui dit que "The classes in a package a reused together. If you reuse one of the classes in a package, you reuse them all"

Ce résultat théorique n'est pas toujours pratique à mettre en oeuvre (du fait de la nécessité d'une classe dérivée dans certains cas) mais pour un grand nombre de cas d'injection de dépendances, il suffit amplement.

Et, ce qui n'est pas pour me déplaire, dans un langage pas trop mal fichu, il me donne l'occasion d'écrire un "framework" basique d'injection de dépendances en 5 ou 6 lignes de code :

public static class MyDIContainer
{
  public static ABSTRACTION GetDetailsFor<ABSTRACTION>(this Assembly a)
  {
      var candidates = a.GetTypes().Where(t => typeof(ABSTRACTION).IsAssignableFrom(t));
      if(candidates.Count() != 1)
        throw new ApplicationException(string.Format("Cannot find unique implementation of {0} in {1}", typeof(ABSTRACTION), a));
      return (ABSTRACTION) Activator.CreateInstance(candidates.First());
  }
}

Ce "framework", qui se contente de retrouver dans un package donné l'unique classe qui implémente une interface donnée, s'utilise de la façon suivante :

var context = Assembly.LoadFile("DependenciesToInject.dll");
var instance = context.GetDetailsFor<IAmAnAbstraction>();

Une manière simple d'étendre ce "framework" pour prendre la main sur la phase de construction des instances, c'est de rajouter une interface "IProvideCustomDetails" et de l'implémenter dans les packages qui ont besoin de cette spécificité.

public interface IProvideCustomDetails
{
  ABSTRACTION GetDetailsFor<ABSTRACTION>() where ABSTRACTION : class;
}

public static class MyDIContainer
{
  public static ABSTRACTION GetDetailsFor<ABSTRACTION>(this Assembly a) where ABSTRACTION : class
  {
    return a.GetCustomDetailsFor<ABSTRACTION>() ?? a.GetUniqueImplementationFor<ABSTRACTION>();
  }
	
  public static ABSTRACTION GetUniqueImplementationFor<ABSTRACTION>(this Assembly a) where ABSTRACTION : class
  {
    var candidates = a.GetTypes().Where(t => typeof(ABSTRACTION).IsAssignableFrom(t));
    if(candidates.Count() != 1)
      throw new ApplicationException(string.Format("Cannot find unique implementation of {0} in {1}", typeof(ABSTRACTION), a));
    return (ABSTRACTION) Activator.CreateInstance(candidates.First());
  }
	
  public static ABSTRACTION GetCustomDetailsFor<ABSTRACTION>(this Assembly a) where ABSTRACTION : class
  {
    var provider = a.GetUniqueImplementationFor<IProvideCustomDetails>();
    return ( provider == null ) ? null : provider.GetDetailsFor<ABSTRACTION>();
  }
}

Bien évidemment, ce genre de code ne va pas rendre l'intégralité des services que rendrait un conteneur de DI "prêt à l'emploi" mais, en ce qui me concerne, je n'ai pas besoin de beaucoup plus que ça (typiquement j'aurais tendance à rajouter un passage de données de configuration à l'appel GetDetailsFor). Je n'ai donc aucune incitation pour utiliser des choses bien plus compliquées et qui nécessitent un suivi ne serait-ce que pour intégrer les mises à jour qui ne manquent pas de fleurir.

Peut être que ce choix n'est finalement qu'une question de contexte de développement. Un développeur qui vogue de projet en projet aura tout intérêt à débarquer avec une panoplie de connaissances directement utilisables. La maîtrise d'un ou plusieurs DI container du marché en fait partie. Cela peut permettre de gagner du temps lors d'un démarrage de projet.
Mais un développeur qui passe des années à faire évoluer les mêmes produits, a-t-il le même intérêt ?
Gardons cela pour un autre débat...

Faut-il encore parler de méthodes agiles en 2012 ?

Oaz — Tue, 03 Jan 2012 14:03:00 +0100

Les années passent et je me dis de plus en plus souvent : mais pourquoi encore parler de méthodes agiles ?
Pourquoi garder ce terme restrictif alors que l'on devrait, à mon avis, tout simplement parler de méthodes professionnelles de développement logiciel ?

Car c'est bien de cela dont il s'agit : des valeurs, des principes et des pratiques qui guident toute activité de développement logiciel et qui caractérisent, sans fausse modestie ni dédain, le professionnalisme nécessaire à la satisfaction des utilisateurs et à la pérennité de l'ouvrage.

En ce début d'année 2012, je ne vais donc prendre qu'une seule résolution pour toutes mes activités qui tournent autour du développement logiciel : parler le moins possible de méthodes agiles et le plus possible de méthodes professionnelles.

Et pour sortir du carcan des "méthodes agiles", quoi de mieux que de commencer l'année avec une rencontre axée sur l'écriture de code, activité majeure de tout développement logiciel ?
Le 5 janvier, c'est la première du software craftsmanship Toulouse (il y aurait aussi beaucoup à dire sur le terme craftsmanship mais chaque chose en son temps...)

Dans mon agenda "agile", j'enchainerai les 2 et 3 février avec une réunion de sensibilisation aux méthodes agiles pour les enseignants des IUT Informatique où j'aurai le plaisir d'intervenir.
Malgré un programme pédagogique national des DUT informatique assez ancien, il y a des choses qu'un diplomé de 2012 qui se lance dans le développement logiciel devrait savoir et toute action de promotion/sensibilisation ne peut aller que dans le bon sens.
J'y animerai probablement un des ateliers ludiques sur l'importance des principes de conception pour garder un logiciel maintenable ou sur la place des artefacts de test dans le TDD. Cela m'évitera de parler de méthodes agiles (ce que d'autres feront bien mieux que moi).

Ce début d'année bien rempli se poursuivra les 16 et 17 mars à Banyuls sur mer pour le premier Agile Open Sud. La rencontre entre une trentaine de passionnés^[1] promet d'être enrichissante.
J'y aborderai peut-être le sujet de la place des méthodes agiles. Sommes-nous contraints à vivre éternellement dans cet enclos pour bêtes curieuses du développement logiciel ? Est-ce aller trop loin que de suggérer le caractère non-professionnel de ceux qui resteraient scotchés sur des approches d'un autre siècle ?

Mais mon principal chantier de l'année sera certainement de prendre du recul sur le chemin parcouru avec la même équipe de développement depuis six ans. Aujourd'hui, je n'utilise pas quotidiennement une méthode agile. Je ne fais que développer une famille de produits logiciels en adaptant jour après jour la manière de travailler. Après avoir fait, il y trois ans, un premier bilan sur la mise en place de Scrum, il me faudrait faire une synthèse sur tout ce qui a changé depuis : des itérations au flux, des estimations à la décomposition, des tests manuels aux tests automatisés et à l'exploration, l'architecture centrée sur le métier, l'apprentissage en continu...

Je ne parlerai peut être plus de méthodes agiles mais je vais encore parler de développement logiciel pendant un certain temps.

Notes

[1] il reste encore des places mais ça devrait partir, je pense, assez vite

Boucles à base de générateurs et de transformations : un exemple plus complet

Oaz — Sat, 24 Dec 2011 11:24:00 +0100

Dans un billet précédent, j'avais évoqué une approche pour l'écriture de boucles permettant d'expliciter la combinaison de diverses exigences.
Le reproche fait dans les commentaires de ce billet est que cette approche serait moins lisible et rendrait inutilement le code plus compliqué.

Pour ma part, je campe sur mes positions. L'approche n'est moins lisible que pour des exemples triviaux que l'on ne rencontre jamais dans un programme réel.
La complexité inhérente à ces programmes fait que, au final, un programme est plus facilement maintenu s'il se base sur une combinaison de générateurs et de transformations indépendantes que s'il se base sur des boucles où tous les ingrédients sont mélangés.

Ce débat me semble par ailleurs être une illustration de la différence entre "simple" et "facile" mise en lumière par Rich Hickey. Les boucles while/for sont certainement plus faciles à écrire au début mais elle ne donnent pas ce qu'il y a de plus simple à maintenir et faire évoluer.

Essayons donc de voir ce que cela donne avec un programme à peine plus riche que des exemples d'une ou deux lignes.

Soit un programme qui :

demande à l'utilisateur de choisir une fonction parmi les suivantes :
- mettre un entier au carré
- calculer la somme des entiers inférieurs ou égaux à un entier donné
- calculer le k-ième terme de la suite de Syracuse à partir d'un entier donné, k étant un entier saisi par l'utilisateur
demande à l'utilisateur de choisir un filtre parmi les suivants :
- prendre les k premiers éléments, k étant un entier saisi par l'utilisateur
- prendre les éléments inférieurs ou égaux à k, k étant un entier saisi par l'utilisateur
- prendre les éléments impairs inférieurs ou égaux à k, k étant un entier saisi par l'utilisateur
Lorsque l'utilisateur a fait ces choix, affiche les images par la fonction choisie précédemment des entiers naturels strictement positifs restreints au filtre lui aussi choisi précédemment

Exemples d'utilisation :

L'utilisateur choisit "mise au carré", puis "4 premiers éléments". Le programme affiche : 1, 4, 9, 16
L'utilisateur choisit "somme des entiers inférieurs ou égaux", puis "impairs inférieurs à 17". Le programme affiche : 1, 3, 15
L'utilisateur choisit "3ème terme de la suite de Syracuse", puis "éléments inférieurs à 6". Le programme affiche : 2, 4, 5, 1

Voici une implémentation à base de générateurs et de transformations. Le code complet est disponible sur github.

J'ai essayé de décrire la démarche étape par étape mais je ne parle pas de ce qui a, dans le cas présent, un intérêt moindre, comme par exemple le découplage au niveau de l'"interface utilisateur" pour faciliter l'écriture des tests.

Allons-y.

J'écris un test pour le cas "mettre un entier au carré" + "prendre les k premiers éléments, k étant un entier saisi par l'utilisateur" et je ne me prends pas la tête pour son implémentation.

[Test]
public void Compute_Square_For_FourFirstItems()
{
  var ui = new FakeUserInteraction(
    "square", "first items", "4"
  );
  Computer.Execute(ui);
  Assert.That (ui.DisplayedMessage,
    Is.EqualTo("1, 4, 9, 16"));
}

public class Computer
{
  public static void Execute(ITalkToUser ui)
  {
    ui.Display("1, 4, 9, 16");
  }
}

Je rajoute un test pour le même cas mais avec un k différent. Après une implémentation naïve, le refactoring m'amène à faire une boucle "for" sur le nombre d'éléments et à afficher et à calculer les carrés dans cette boucle.
Il est évident que, à cet instant, je n'ai pas un besoin impérieux de faire appel à d'autres concepts.

[Test]
public void Compute_Square_For_FiveFirstItems()
{
  var ui = new FakeUserInteraction(
    "square", "first items", "5"
  );
  Computer.Execute(ui);
  Assert.That (ui.DisplayedMessage,
    Is.EqualTo("1, 4, 9, 16, 25"));
}

public static void Execute(ITalkToUser ui)
{
  var dontCare = ui.Ask("choose operation");
  var dontCareAgain = ui.Ask("choose filter");
  var numberOfItems = int.Parse(ui.Ask("number of items"));
  var results = new List<int>();
  for(var i=1; i <= numberOfItems; i++)
    results.Add(i*i);
  ui.Display(string.Join(", ", results));
}

Je rajoute un test pour le cas "mettre un entier au carré" + "prendre les éléments inférieurs ou égaux à k, k étant un entier saisi par l'utilisateur" et je commence par une implémentation naïve pour passer au vert.

[Test]
public void Compute_Square_For_UnderTwenty()
{
  var ui = new FakeUserInteraction(
    "square", "under", "20"
  );
  Computer.Execute(ui);
  Assert.That (ui.DisplayedMessage,
    Is.EqualTo("1, 4, 9, 16"));
}

public static void Execute(ITalkToUser ui)
{
  var dontCare = ui.Ask("choose operation");
  var filter = ui.Ask("choose filter");
  if( filter == "under" )
  {
    ui.Display("1, 4, 9, 16");
  }
  else
  {
    var numberOfItems = int.Parse(ui.Ask("number of items"));
    var results = new List<int>();
    for(var i=1; i <= numberOfItems; i++)
      results.Add(i*i);
    ui.Display(string.Join(", ", results));
  }
}

Un premier refactoring m'amène à rendre similaires les deux cas : ce sont tous les deux des boucles qui calculent des carrés

public static void Execute(ITalkToUser ui)
{
  var dontCare = ui.Ask("choose operation");
  var filter = ui.Ask("choose filter");
  var results = new List<int>();
  if( filter == "under" )
  {
    var maxValue = int.Parse(ui.Ask("max value"));
    for(var i=1; i*i <= maxValue; i++)
      results.Add(i*i);
  }
  else
  {
    var numberOfItems = int.Parse(ui.Ask("number of items"));
    for(var i=1; i <= numberOfItems; i++)
      results.Add(i*i);
  }
  ui.Display(string.Join(", ", results));
}

Un deuxième refactoring m'amène à extraire la fonction qui détermine le point d'arrêt de la boucle. On notera l'utilisation de lambda expressions avec fermeture pour capturer le paramètre k de la condition d'arrêt (soit un nombre d'éléments, soit une valeur maximale).
J'ai toujours ma boucle "for" mais je viens de réaliser une opération importante : le choix de la condition d'arrêt est, dans sa totalité (incluant le dialogue utilisateur), externalisé dans une fonction "ChooseFilter".

public static void Execute(ITalkToUser ui)
{
  var dontCare = ui.Ask("choose operation");
  var results = new List<int>();
  var untilConditionIsVerifiedFor = ChooseFilter(ui);
  for(var i=1; untilConditionIsVerifiedFor(i); i++)
    results.Add(i*i);
  ui.Display(string.Join(", ", results));
}

static Func<int,bool> ChooseFilter(ITalkToUser ui)
{
  var filter = ui.Ask("choose filter");
  if( filter == "under" )
  {
    var maxValue = int.Parse(ui.Ask("max value"));
    return i => (i*i <= maxValue);
  }
  else
  {
    var numberOfItems = int.Parse(ui.Ask("number of items"));
    return i => (i <= numberOfItems);
  }
}

Je rajoute un test pour le cas "calculer la somme des entiers inférieurs ou égaux à un entier donné" + "prendre les k premiers éléments, k étant un entier saisi par l'utilisateur".
Comme toujours, je commence par une implémentation qui me permet de rapidement passer au vert.

[Test]
public void Compute_IntegerSum_For_FiveFirstItems()
{
  var ui = new FakeUserInteraction(
    "integer sum", "first items", "5"
  );
  Computer.Execute(ui);
  Assert.That (ui.DisplayedMessage,
    Is.EqualTo("1, 3, 6, 10, 15"));
}

public static void Execute(ITalkToUser ui)
{
  var results = new List<int>();
  var operation = ui.Ask("choose operation");
  if( operation == "integer sum" )
  {
    results.AddRange(new int[] {1,3,6,10,15});
  }
  else
  {
    var untilConditionIsVerifiedFor = ChooseFilter(ui);
    for(var i=1; untilConditionIsVerifiedFor(i); i++)
      results.Add(i*i);
  }
  ui.Display(string.Join(", ", results));
}

Ensuite, toujours la même approche : je rends les deux cas similaires. En l'occurrence, j'explicite la boucle de calcul des "sommes de n premiers entiers"

public static void Execute(ITalkToUser ui)
{
  var results = new List<int>();
  var operation = ui.Ask("choose operation");
  if( operation == "integer sum" )
  {
    var untilConditionIsVerifiedFor = ChooseFilter(ui);
    for(var i=1; untilConditionIsVerifiedFor(i); i++)
      results.Add(i*(i+1)/2);
  }
  else
  {
    var untilConditionIsVerifiedFor = ChooseFilter(ui);
    for(var i=1; untilConditionIsVerifiedFor(i); i++)
      results.Add(i*i);
  }
  ui.Display(string.Join(", ", results));
}

Pour terminer le refactoring, j'externalise le choix de l'opération.

public static void Execute(ITalkToUser ui)
{
  var results = new List<int>();
  var operation = ChooseOperation(ui);
  var untilConditionIsVerifiedFor = ChooseFilter(ui);
  for(var i=1; untilConditionIsVerifiedFor(i); i++)
    results.Add(operation(i));
  ui.Display(string.Join(", ", results));
}

static Func<int,int> ChooseOperation(ITalkToUser ui)
{
  var operation = ui.Ask("choose operation");
  if( operation == "integer sum" )
  {
    return i => i*(i+1)/2;
  }
  else
  {
    return i => i*i;
  }
}

Je rajoute maintenant le cas de test "calculer la somme des entiers inférieurs ou égaux à un entier donné" + "prendre les éléments inférieurs ou égaux à k, k étant un entier saisi par l'utilisateur".
Une première implémentation m'amène à modifier le choix de la condition d'arrêt en y injectant l'opération réalisée.

[Test]
public void Compute_IntegerSum_For_UnderTwelve()
{
  var ui = new FakeUserInteraction(
    "integer sum", "under", "12"
  );
  Computer.Execute(ui);
  Assert.That (ui.DisplayedMessage,
    Is.EqualTo("1, 3, 6, 10"));
}

public static void Execute(ITalkToUser ui)
{
  var results = new List<int>();
  var operation = ChooseOperation(ui);
  var untilConditionIsVerifiedFor = ChooseFilter(ui,operation);
  for(var i=1; untilConditionIsVerifiedFor(i); i++)
    results.Add(operation(i));
  ui.Display(string.Join(", ", results));
}

static Func<int,bool>
ChooseFilter(ITalkToUser ui, Func<int,int> operation)
{
  var filter = ui.Ask("choose filter");
  if( filter == "under" )
  {
    var maxValue = int.Parse(ui.Ask("max value"));
    return i => (operation(i) <= maxValue);
  }
  else
  {
    var numberOfItems = int.Parse(ui.Ask("number of items"));
    return i => (i <= numberOfItems);
  }
}

Cela fonctionne mais me laisse insatisfait : j'avais réussi à découpler le choix de la condition d'arrêt de l'opération et là j'ai dû réintroduire le couplage.
Pour corriger cela, il me faut sortir de la logique de la boucle "for". Je vais commencer par changer la structure de la boucle en introduisant un générateur de nombre entiers suivi d'un filtre (TakeWhile) et d'une projection (Select).

public static void Execute(ITalkToUser ui)
{
  var operation = ChooseOperation(ui);
  var conditionIsVerified = ChooseFilter(ui,operation);
  var results = Integers()
    .TakeWhile (conditionIsVerified)
    .Select (operation);
  ui.Display(string.Join(", ", results));
}

static IEnumerable<int> Integers()
{
  int n = 1;
  while(true)
  {
    yield return n;
    n++;
  }
}

Dans un deuxième temps, je change l'écriture de mon filtre : plutôt que d'utiliser un TakeWhile avec une condition d'arrêt qui dépend du résultat de l'opération, je crée une fonction de filtrage qui dépend directement du choix utilisateur.

public static void Execute(ITalkToUser ui)
{
  var operation = ChooseOperation(ui);
  var results = Integers().Select(operation);
  var filteredResults = ChooseFilter(ui)(results);
  ui.Display(string.Join(", ", filteredResults));
}

static Func<IEnumerable<int>,IEnumerable<int>>
  ChooseFilter(ITalkToUser ui)
{
  var filter = ui.Ask("choose filter");
  if( filter == "under" )
  {
    var maxValue = int.Parse(ui.Ask("max value"));
    return e => e.TakeWhile( n => n <= maxValue);
  }
  else
  {
    var numberOfItems = int.Parse(ui.Ask("number of items"));
    return e => e.Take(numberOfItems);
  }
}

A ce stade de l'écriture de mon programme, où j'ai implémenté 2 types d'opérations et 2 types de filtres, j'ai réussi à séparer les divers concepts.
Je me retrouve donc avec quatre éléments indépendants :

un générateur de nombre entiers
la définition d'une opération en quelques lignes à partir d'éléments externes (un choix utilisateur)
la définition d'un filtre en quelques lignes sur des entiers à partir d'autres éléments externes (un autre choix utilisateur)
une fonction principale qui ne dépend pas directement des éléments externes et qui tient en 4 lignes tout en restant limpide

public class Computer
{
  public static void Execute(ITalkToUser ui)
  {
    var operation = ChooseOperation(ui);
    var results = Integers().Select(operation);
    var filteredResults = ChooseFilter(ui)(results);
    ui.Display(string.Join(", ", filteredResults));
  }

  static IEnumerable<int> Integers()
  {
    int n = 1;
    while(true)
    {
      yield return n;
      n++;
    }
  }

  static Func<int,int> ChooseOperation(ITalkToUser ui)
  {
    var operation = ui.Ask("choose operation");
    if( operation == "integer sum" )
    {
      return i => i*(i+1)/2;
    }
    else
    {
      return i => i*i;
    }
  }

  static Func<IEnumerable<int>,IEnumerable<int>> ChooseFilter(ITalkToUser ui)
  {
    var filter = ui.Ask("choose filter");
    if( filter == "under" )
    {
      var maxValue = int.Parse(ui.Ask("max value"));
      return e => e.TakeWhile( n => n <= maxValue);
    }
    else
    {
      var numberOfItems = int.Parse(ui.Ask("number of items"));
      return e => e.Take(numberOfItems);
    }
  }
}

L'état où nous nous trouvons actuellement présente deux avantages (qui vont généralement de paire) :

le code a une structure simple (éléments indépendants) qui reste facile à comprendre pour peu que l'on fasse l'effort d'apprendre des concepts qui vont au delà de l'écriture "classique" des boucles en programmation impérative.
le code est maintenable : on va pouvoir faire évoluer les éléments indépendants sans toucher aux autres. C'est ce que nous allons voir tout de suite.

Je rajoute un test pour le cas "calculer la somme des entiers inférieurs ou égaux à un entier donné" + "prendre les éléments impairs inférieurs ou égaux à k, k étant un entier saisi par l'utilisateur".
La nouveauté ici est le filtre sur les éléments impairs.
Sans surprise, il me suffit de modifier la définition du filtre en fonction des choix utilisateurs sans toucher aux autres parties du code.

[Test]
public void
Compute_IntegerSum_For_OddUnderSeventeen()
{
  var ui = new FakeUserInteraction(
    "integer sum", "odd under", "17"
  );
  Computer.Execute(ui);
  Assert.That (ui.DisplayedMessage,
    Is.EqualTo("1, 3, 15"));
}

static Func<IEnumerable<int>,IEnumerable<int>>
  ChooseFilter(ITalkToUser ui)
{
  var filter = ui.Ask("choose filter");
  if( filter == "odd under" )
  {
    var maxValue = int.Parse(ui.Ask("max value"));
    return e => e.TakeWhile( n => n <= maxValue ).Where( n => n%2==1 );
  }
  else if( filter == "under" )
  {
    var maxValue = int.Parse(ui.Ask("max value"));
    return e => e.TakeWhile( n => n <= maxValue );
  }
  else
  {
    var numberOfItems = int.Parse(ui.Ask("number of items"));
    return e => e.Take(numberOfItems);
  }
}

Si je veux rajouter une opération, même une qui ne soit pas triviale, pas de problème non plus : je ne modifie que la partie "ChooseOperation".

Je rajoute un test pour le cas "calculer le k-ième terme de la suite de Syracuse à partir d'un entier donné, k étant un entier saisi par l'utilisateur" + "prendre les éléments inférieurs ou égaux à k, k étant un entier saisi par l'utilisateur".

[Test]
public void
Compute_SyracuseThirdItem_For_UnderSix()
{
  var ui = new FakeUserInteraction(
    "syracuse", "3", "under", "6"
  );
  Computer.Execute(ui);
  Assert.That (ui.DisplayedMessage,
    Is.EqualTo("2, 4, 5, 1"));
}

static Func<int,int> ChooseOperation(ITalkToUser ui)
{
  var operation = ui.Ask("choose operation");
  if( operation == "syracuse" )
  {
    var rank = int.Parse(ui.Ask("rank"));
    return i => SyracuseSequence(i).ElementAt(rank-1);
  }
  else if( operation == "integer sum" )
  {
    return i => i*(i+1)/2;
  }
  else
  {
    return i => i*i;
  }
}

static IEnumerable<int> SyracuseSequence(int seed)
{
  var n = seed;
  while(true)
  {
    yield return n;
    if(n%2==0)
      n = n/2;
    else
      n = 3*n+1;
  }
}

J'espère avoir pu montrer que l'utilisation de générateurs et de diverses transformations (projections, filtres) pouvait avantageusement remplacer des boucles qui deviennent rapidement trop complexes dès que l'on est confronté à une variété de cas qui vont au delà du simple calcul et de la simple condition d'arrêt.

Et je crois qu'il ne faut pas se bloquer sur quelques concepts qui peuvent paraitre, au début, trop complexes pour ce que l'on veut faire. On y gagne rapidement en lisibilité et maintenabilité et, avec l'habitude, cette façon d'écrire devient aussi naturelle que les structures de boucle plus connues.