Les méthodes agiles à proprement parler ne fournissent pas de solution clé en main dans ce domaine. C’est donc au travers du système de valeurs et des retours d’expérience que l’on cherchera à répondre à cette question.

Le premier élément de réponse provient de l’une des pratiques issues de l’eXtreme Programming et nommée la métaphore. Une métaphore est une abstraction de niveau élevé destinée à décrire les principes d’architecture mis en oeuvre dans un système ou un sous-système. Difficile à mettre en forme, le principe de métaphore se traduit souvent par un bref dossier d’architecture – 10 pages maximum – que chaque équipe est chargée de maintenir et de publier (généralement dans un wiki).
Un très bon exemple illustrant ce principe de la métaphore a été récemment fourni par l’équipe Chrome de Google, qui a publié sa métaphore sous la forme d’une BD de 38 pages. Y sont expliqués la vision du produit et les principes architecturaux qui guident sa mise en oeuvre, ainsi que les raisons des choix réalisés.

La seconde réponse à la question de l’architecture est dérivée d’une pratique d’ingénierie héritée du Lean Manufacturing, et que l’on retrouve dans la plupart des méthodologies, agiles ou non : les standards de développement.

Les systèmes organiques mis en place par certains acteurs majeurs du Web fonctionnent sur ce principe : une myriade d’équipes de petite taille sont chargées de développer des services ou composants fortement intégrés. Chaque équipe inclut un technicien chevronné qui prend le rôle de « Architecture Owner ». Elle conservent une totale autonomie technique et la maîtrise de leur cycle de vie mais sont soumises à un ensemble de règles qui régissent la façon dont ces composants sont interfacés avec le reste du système.

Ces règles couvrent, sans exhaustivité :

• l’exploitabilité (socle technique pris en charge par les équipes d’exploitation)
• la supervision (indicateurs, alertes, traces, journaux, etc.)
• l’assemblage (afin d’automatiser les déploiements)
• la qualité de service (charge, temps de réponse, sécurité, etc.)
• l’interopérabilité (protocoles et paradigmes d’échange, modalités d’intégration, etc.)

Ces règles sont mises au point par le collège des architectes (architecture owners) et consolidées par un « Chief Architect » dont le rôle est de les diffuser et d’en garantir la consistance. Des ateliers sont régulièrement organisés, réunissant les architectes des différents produits, afin d’échanger sur les solutions aux problématiques transverses qui peuvent se poser.

Au besoin, certains concepts d’architecture éprouvés peuvent être encapsulés dans des composants partagés. On peut, par exemple, mettre à disposition des équipes une API de persistance qui encapsule les stratégies de partitionnement des bases de données et la gestion transactionnelle. Une autre API prendra en charge les paradigmes d’échange (essentiellement asynchrone) mis en oeuvre dans l’architecture. Ces développements sont idéalement pris en charge par des équipes ad hoc, et placés sous la responsabilité collective. Si le contexte l’exige, on peut constituer une équipe dédiée (cf. un peu plus bas).

Notons que cette approche n’est envisageable que si l’architecture globale est fortement modulaire.

Une autre approche possible est mise en place sur certains projets agiles de grande taille. Cette solution consiste, au sein d’un projet nécessitant plusieurs équipes, à spécialiser une équipe dans les aspects architecturaux (on parle d’ « Architecture Team », en complément de « Feature Teams » chargées de développer les fonctionnalités du produit). C’est une telle organisation que nous vous avons présentée dans ce retour d’expérience. Sur des projets de très grande taille, d’autres équipes spécialisées peuvent émerger : intégration du système, équipe de tests dédiée, etc.

Quelle que soit la structure choisie, on retiendra un certain nombre de principes, exprimés par Scott Ambler (Practice Leader Agile Development chez IBM Rational) dans un article parut en 2006 dans le Agile Journal :

• Modéliser à plusieurs – l’architecture et la modélisation devraient être réalisées en groupe, afin de bénéficier de l’expérience de chacun et de consolider une vision commune, une culture collective
• Se focaliser sur la collaboration plutôt que sur la documentation – un architecte agile est un membre actif des équipes de développement, et non un simple producteur de documents à destination des dites équipes ; cela ne signifie pas qu’il ne faut pas documenter, mais la documentation doit être vue comme un effort secondaire
• Prouver par le code – le prototypage doit être systématisé afin de lever les risques au plus tôt
• Rester simple – une des pierres angulaire du développement agile : le modèle et l’architecture n’ont besoin de satisfaire que les besoins identifiés
• Utiliser les outils les plus simples – bien souvent, un simple tableau et quelques marqueurs suffisent
• Adresser les grandes problématiques très tôt – les paradigmes d’architecture doivent être identifiés dès les phases initiales du projet, sous la forme d’une vision (ou d’une métaphore, pour reprendre la terminologie XP) ; à l’échelle du SI, cela peut se traduire par un plan d’urbanisme de très haut niveau, assorti de règles d’intégration de type SOA (mise en place de services HTTP, mode de communication prioritairement asynchrone, politiques de gestion de versions et d’adressage, modalités d’intégration des IHM, etc.)
• Penser aux détails « just-in-time » – les détails du modèle et de l’architecture sont élaborés le plus tard possible par les équipes de développement ; au même titre que le développement, la conception est une activité continue
• Permettre à l’architecture d’émerger avec le temps – même si une vision est conçue au départ, les détail émergerons au rythme des évolutions du système
• Voyager léger – ne pas écrire 50 pages quand 5 suffisent ; ne pas écrire 5 pages quand un diagramme suffit ; ne pas faire un diagramme si une métaphore suffit.
• Maintenir quelques diagrammes de haut niveau – voyager léger ne signifie pas que toute documentation disparaît ; quelques diagrammes permettant de naviguer dans l’architecture sont utiles
• Rester flexible – le type de diagramme de haut niveau dépend du système et du contexte ; ils ne devraient pas faire l’objet d’une règle rigide
• Publier les modèles d’architecture – ils doivent être accessibles aux membres de l’équipe et à tous ceux qui souhaitent les consulter
• Piloter l’architecture par les besoins

Rappelons rapidement les principales techniques de teamicide décrites dans Peopleware :

• Le management défensif – résultat direct d’une défiance irréfléchie envers l’équipe, et qui se manifeste sous diverses formes plus ou moins spectaculaires, mais toujours avec le même objectif : réduire autant que possible les degrés de liberté des membres de l’équipe.
• La bureaucratie, qui, dans le développement logiciel, prend souvent la forme d’une méthodologie formelle impliquant un grand nombre de documents d’étape dont l’intérêt douteux n’en entame pas moins le caractère sacré. Dans les organisations les plus avancées dans le domaine, on observe souvent une cellule spéciale qui agit en tant que police de la Méthode et vérifie scrupuleusement qu’aucune équipe n’a enfreint les tables de la Loi. Cette approche permet de cumuler bureaucratie et management défensif.
• La séparation physique des individus, dont on comprend sans peine qu’elle réduit mécaniquement les relations interpersonnelles entre eux.
• La fragmentation du temps – demander aux gens de travailler à temps partiel sur plusieurs projets simultanément est l’une de ces recettes magiques qui, outre qu’elle réduit fortement l’efficacité des individus, interdit à coup sûr l’émergence du moindre esprit d’équipe (quelle équipe, au fait ?).
• La réduction de la qualité, qui est une technique plus subtile mais non moins efficace et populaire de teamicide. Il n’est tout bonnement pas imaginable qu’une équipe émerge formée d’individus honteux de leur travail …
• Les délais arbitraires et intenables, qu’un nombre encore impressionnant de cadres s’acharnent à considérer comme un moyen astucieux de conserver une équipe sous pression. Mettre d’emblée une équipe en situation d’échec, en lui fixant des objectifs qu’elle n’a aucune chance d’atteindre, est pourtant le plus sûr moyen de voir s’évaporer toute trace de motivation, tant collective qu’individuelle …

Fort de ces quelques indices, on comprend aisément que le développement offshore est un terrain spontanément très propice au teamicide. Tellement propice au demeurant que la plupart des organisations offshore baissent d’emblée les bras et ne cherchent même pas à construire des équipes – elles se contentent d’agréger des jours-homme au meilleur coût dans l’espoir souvent déçu que cette masse d’effort pourra être canalisée vers un résultat tangible. Elles utilisent pour cela des techniques de management qui pour la plupart finissent par achopper, précisément parce qu’elles sont de nature teamicidaires et que l’on n’échappe jamais vraiment à l’impératif de constituer d’authentiques équipes pour réussir un projet.

Depuis plus de trois ans maintenant, Xebia mène des projets agiles distribués, grâce à des équipes transcontinentales dont une partie des membres est localisée à Gurgaon, dans la banlieue de Delhi. Rappelons que la construction d’équipes de petite taille et fortement autonomes est une condition sine qua non de succès dans un projet agile, fût-il mené en offshore. Tout l’enjeu de l’approche ADDM (Agile Distributed Delivery Model) est donc précisément de parvenir à constituer de véritables équipes dont les membres sont distants de 6000 km les uns des autres et issus de substrats culturels radicalement différents.

Cet impératif nous a permis de découvrir, parfois dans la douleur, tout un jeu de techniques teamicidaires inédites. Attention : l’usage d’une ou plusieurs de ces techniques constitue le meilleur moyen d’échouer rapidement dans un projet agile distribué. En voici les 10 principales, :

1. Impliquer l’équipe offshore après quelques sprints, une fois que l’équipe locale a bien compris les enjeux du projet, réalisé les principaux choix techniques et élaboré une road-map
2. Une fois l’équipe offshore intégrée, continuer de prendre localement les principales décisions en matières d’architecture et de conception. Communiquer fréquemment sur l’incapacité de l’équipe offshore à bien comprendre ces choix, et sur les erreurs qui en découlent.
3. Attribuer à l’équipe offshore tous les problèmes du projet, fussent-ils dus à des exigences floues, à de la dette technique ou encore à des choix technologiques erronés. Vous serez surpris de constater à quel point il est aisé, aux yeux de vos commanditaires, de faire porter le chapeau à l’équipe distante.
4. Rester condescendant lors des rétrospectives, sans jamais donner de feedback honnête à l’équipe offshore. Lui assurer systématiquement que son travail est excellent, quelle qu’en soit la réalité.
5. Ne jamais colocaliser toute l’équipe et maintenir l’équipe offshore à distance du Product Owner, des utilisateurs, et plus généralement de toutes les parties prenantes du projet. Invoquer le coût du voyage permet très aisément de convaincre le management du bien fondé de cette mesure.
6. Si malgré tout une période de colocalisation est organisée, s’assurer que les développeurs offshore ne programment jamais en binôme avec leurs pairs locaux. Si possible, placer les premiers dans un bureau distinct.
7. Confier à l’équipe offshore les tâches dont personne d’autre ne veut, et réserver les user stories les plus stimulantes pour l’équipe locale.
8. Remanier le code durant le weekend, ou en l’absence de l’équipe offshore (l’après-midi, si ce sont des Indiens), en se gardant de l’informer sur ce refactoring.
9. Ré-écrire le code produit par l’équipe offshore, sans communiquer avec elle sur les raisons de cette mesure. En complément, faire en sorte que le management soit informé du retard pris par le projet en raison de cette ré-écriture.
10. Ne jamais permettre à l’équipe offshore de corriger les problèmes qu’elle a elle-même introduits.

A bien y regarder cependant la neutralité du forfait vis à vis du processus de développement est moins évidente. Conçu historiquement pour satisfaire aux exigences de mise en concurrence des fournisseurs du Département de la Défense américain, le contrat au forfait est né du même substrat que le processus de développement en cascade – initialement décrit en 1970 par Winston W. Royce dans Managing the developpement of large software systems.

Ce processus de développement est aujourd’hui fortement remis en question, sous le constat empirique de son échec relatif, et sous l’impulsion des méthodes agiles. Je pense quant à moi que la « cascade » sera perçue dans quelques années comme l’aveuglement juvénile d’une industrie encore adolescente, à la recherche de son identité.

La question qui nous intéresse ici est de savoir si le projet au forfait survivra à la cascade. Autrement dit s’il est possible de mener au forfait un projet agile sous-traité. Certains le pensent, et certains intégrateurs proposent au demeurant de tels contrats. J’entends quant à moi démontrer ici que l’agilité et le forfait reposent sur des logiques financières radicalement antinomiques, qui les rendent difficilement conciliables.

Un petit tour du côté de l’étymologie devrait alerter les adeptes du forfait. Forfait vient du vieux français fors faire qui signifie… faire du mal !

Dans un contrat au forfait, le client définit ce qu’il souhaite sous la forme d’un cahier des charges. En retour, le fournisseur doit s’engage à livrer ce qui est décrit pour un coût et dans un délai fixes – les deux faisant l’objet d’une négociation initiale ou d’une mise en concurrence.

Ce contrat n’est pas franchement équitable : il est conçu pour protéger le client et fait porter très fortement le risque sur le fournisseur, qui doit s’engager sur un délai, sur un coût et sur un périmètre (fixé par le cahier de charges). L’efficacité réelle de cette protection reste cependant en grande partie illusoire : il n’est pas rare que le déploiement d’une application relève de l’intérêt vital d’une organisation et que l’abandon suivi d’un contentieux judiciaire ne soit pas une véritable option, quels que soient les recours légaux qu’autorise le contrat.

De leur côté, et très schématiquement, les méthodes agiles reposent sur un mode de développement que l’on dit incrémental. Le développement est réalisé en cycles courts, de durée fixe, au terme desquels un logiciel partiel mais opérationnel est livré. Le périmètre de chaque cycle est déterminé au début du cycle, ou peu avant. Les autres fonctionnalités sont maintenues dans un Product Backlog qui est par principe ouvert au changement. En d’autres termes, si au cours du projet certains besoins apparaissent, changent ou disparaissent, ces modifications sont intégrées dans le Product Backlog, et potentiellement implémentées dans le cycle suivant. La réalisation incrémentale permet en outre une gestion des priorités : les fonctionnalités les plus importantes (celles qui ont le plus de valeur) sont placées en haut de la liste, et implémentées en premier. Ce pilotage par la valeur, couplé au caractère incrémental de la réalisation est au cœur de la logique financière des projets agiles – nous y reviendrons.

En somme, pour adhérer aux paradigmes des méthodes agiles, l’un des termes du contrat forfaitaire classique doit être abandonné : le périmètre fixe, généralement incarné par des spécifications techniques et fonctionnelles détaillées.

C’est cet abandon qui me semble improbable.

Pour bien comprendre en quoi cet abandon est incompatible avec un contrat forfaitaire, un petit détour par la la micro-économie est nécessaire.

Le développement incrémental permet de produire en premier lieu les fonctionnalités ayant la plus grande valeur d’usage pour le client (c’est lui qui fixe les priorités). Cette caractéristique renvoi à ce que les économistes appellent l’utilité marginale décroissante.
Le concept d’utilité marginale décroissante est classiquement illustré par le phénomène de la soif : lorsque vous êtes assoiffé, la première gorgée d’eau vous procure une très forte satisfaction (une très grande utilité, donc). A mesure que vous vous désaltérez, chaque nouveau verre vous apporte une satisfaction moindre que le précédent. Si vous devez payer chaque verre, vous cesserez de boire dès que le coût du verre vous semblera excessif en regard de la satisfaction de le boire. Si le verre est gratuit, vous boirez jusqu’à étanchement total de la soif – c’est-à-dire jusqu’au stade où un verre supplémentaire vous causerait du désagrément (il faut vraiment arréter, sinon il est possible d’en mourir !).

Le développement incrémental produit le même phénomène : les fonctionnalités à plus forte valeur ajoutée sont produites en premier. Il est donc naturel que la valeur ajoutée des cycles successifs diminue.

Le graphique suivant illustre schématiquement ce principe d’utilité marginale décroissante :

A chaque cycle, la valeur totale du logiciel augmente, mais la variation de valeur entre deux cycles successifs (c’est-à-dire la valeur marginale) diminue.

Cette vision est bien sûr très stylisée (j’ai utilisée un fonction linéaire de l’utilité marginale pour construire le graphe). Dans la réalité, la valeur marginale est nettement plus variable : au cours du développement, certains besoins à forte valeur ajoutée peuvent émerger ; ils seront intégrés au cycle suivant, augmentant sensiblement son utilité marginale. Symétriquement, certaines fonctionnalités déjà développées peuvent se révéler décevantes : leur valeur d’usage est moindre que celle escomptée – ce qui réduit d’autant la valeur acquise.

Ajoutons qu’au même titre que la satisfaction marginale du buveur d’eau, la valeur marginale du développement peut devenir négative : en effet, toute fonctionnalité une fois développée et déployée possède un coût de possession intrinsèque (ressources, maintenance, supervision, etc.) qui peut dépasser sa valeur propre. Une fonctionnalité inutile dans un logiciel possède typiquement cette caractéristique (il suffit d’être utilisateur des dernières versions de Microsoft Office pour se faire une idée précise de ce phénomène).

En micro-économie, la notion d’utilité marginale décroissante est utile pour expliquer le fonctionnement élémentaire des marchés. Si vous devez payer vos verres d’eau, vous cesserez de boire – et donc de payer – dès que le prix d’un verre vous semblera supérieur à son utilité marginale.

Le même principe est en oeuvre dans un projet agile : le développement devrait prendre fin lorsque le coût d’un cycle supplémentaire excède sa valeur marginale.

Or avec un forfait, ce moment n’arrive jamais !

Je m’explique, vous allez voir, c’est très simple.

Dans un forfait, le prix total est négocié frontalement, et peut donc être considéré en théorie comme un invariant. A contrario, les dépenses totales du fournisseur augmentant avec le temps, sa marge est directement dépendante de la durée des développements (et de ses coûts journaliers).
S’il applique un processus de développement incrémental, il se trouve dans la situation décrite par ce graphique (pour simplifier, on suppose que chaque cycle implique la même dépense que le précédent) :

A chaque nouveau cycle, la dépense totale du fournisseur augmente, et sa marge totale baisse en proportion. Au-delà d’un certain seuil, sa marge devient négative, et il travaille à perte. Pour sa survie, il est indispensable que le projet prenne fin avant le franchissement de ce seuil fatidique.

Logiquement, lorsque la valeur totale du logiciel atteint le prix du forfait, le projet devrait s’interrompre (cet événement a lieu après le 8ème cycle dans notre modèle). A ce moment, la marge du fournisseur est positive, et le client a obtenu une valeur d’usage à hauteur de son investissement. Malheureusement, rien n’incite dans ce modèle le client à déclarer le projet achevé. En effet, ici, le coût marginal d’un cycle est nul – réaliser une itération supplémentaire n’impute pas le budget total. Le client est donc incité à prolonger les développements aussi longtemps que la valeur marginale d’une itération est positive, poussant virtuellement le fournisseur à boire le calice jusqu’à la lie.

Le seul moyen pour le fournisseur de maîtriser ce risque est de définir en amont – contractuellement – le périmètre de sa production logicielle. Il demande au client de s’engager dès le départ sur des spécifications détaillées du logiciel, et protège ce périmètre en le plaçant sous un strict contrôle du changement – chaque évolution faisant l’objet d’un juteux avenant. Dès lors le changement devient un coût pour le client, qui a le choix entre le refuser (au risque de mécontenter ses utilisateurs) ou le payer (au risque de voir son budget exploser de façon incontrôlée). L’un des principes cardinaux des méthodes agiles, l’acceptation du changement, devient tout simplement impraticable.

Dans sa dynamique financière, le contrat au forfait s’avère donc incompatible avec les prédicats du développement incrémental – la glaciation des spécifications est intrinsèque à la gestion du risque par le fournisseur, et c’est en facturant au prix fort le changement qu’il optimisera sa marge. Cette aversion au changement est intrinséquement contradictoire avec les principes agiles.

Il reste bien sûr possible de bricoler quelques dispositions contractuelles offrant un terrain plus favorable aux méthodes agiles dans un projet au forfait. Mais aucune ne pourra effacer véritablement l’incompatibilité fondamentale entre un contrat focalisé sur le coût, et une pratique de développement incrémentale et adaptative.

Cela ne signifie évidemment pas que les méthodes agiles sont incompatibles avec la notion de contrôle budgétaire ou de maîtrise des coûts, bien au contraire. Mais il est indispensable, pour assurer le succès des méthodes agiles dans un contexte de sous-traitance, de repenser la façon dont sont conçues les relations contractuelles entre les parties. Cet aspect fera l’objet d’un très prochain article.

Le concept du plat de spaghetti est familier à quiconque a eu l’occasion de travailler sur des architectures distribuées à grande échelle (ou à petite échelle d’ailleurs). Le principe en est simple : à force de multiplier les interactions point-à-point entre des composants ou systèmes hétéroclites, on tisse une véritable toile de dépendances croisées qui, à une vitesse surprenante, conduit l’ensemble du système à la sclérose. Faire évoluer un composant (ou service) devient une tâche impossible, impactant un nombre croissant (et souvent inconnu) de systèmes tiers qui en sont les clients et, du coup, les victimes.

Le schéma suivant résume l’idée :

En règle générale, on cherche donc, lorsque l’on conçoit une architecture distribuée, à adhérer au paradigme ravioli plutôt qu’à celui spaghetti. Dans l’architecture ravioli, chaque composant est petit, et faiblement couplé aux autres ; il encapsule de la viande et d’autres aliments pour le système ; on peut enlever ou changer un raviolo (oui, au singulier, c’est raviolo, ne serait-ce que pour faire plaisir à une charmante italienne de ma connaissance) sans impacter les autres ravioli. A l’occasion, je vous parlerai plus en détail de la Théorie Générale des Pâtes Appliquée au Génie Logiciel (Pasta Theory on Software, en anglais)…

Pour revenir aux problèmes d’architecture, les ESB sont à première vue un moyen simple de s’affranchir du modèle point-à-point au profit du modèle spoke-hub, en d’autres termes de transformer à peu de frais votre plat de spaghetti en plat de ravioli. Le schéma suivant illustre cette évolution :

Présenté de la sorte, l’ESB fait figure de composant magique. Mais cette vision – que certains n’hésitent pas à exploiter sans vergogne dans leurs arguments commerciaux – néglige la nature duale du couplage dans une architecture distribuée.

En effet, lorsque deux composants (ou systèmes ou services ou applications) établissent une communication point-à-point, ils établissent une dépendance à deux niveaux :

• au niveau technique : les deux systèmes doivent trouver un protocole de communication partagé – et ceci est vrai quelle que soit la sémantique d’échange, synchrone ou asynchrone
• au niveau fonctionnel : les deux systèmes doivent s’entendre sur un format d’échange

Appliqué tel quel, un ESB ne fait que résoudre la problématique de couplage au niveau technique – et c’est rarement le niveau le plus critique (les protocoles de remoting ne changent qu’exceptionnellement, et leurs évolutions assurent le plus souvent la rétrocompatibilité).

Si le couplage fonctionnel n’est pas pris en compte, l’ESB ne fait que déplacer le problème – et nous obtenons notre fameux Enterprise Spaghetti Bus :

D’aucuns prétendront que cette situation est préférable, puisqu’elle permet de gérer la complexité en un point unique, et d’utiliser les services de transformation offerts par l’ESB pour gérer les évolutions dans les formats déchange ; l’argument est probablement recevable sur le court terme, tant que le nombre de services et de versions permet une combinatoire de taille raisonnable. Mais il ne fait aucun doute que rapidement, cette combinatoire va exploser – et avec elle le coût d’évolution de chaque service.

La parade à l’Enterprise Spaghetti Bus existe : elle consiste à définir un format pivot, ou modèle canonique, auquel se conforme les producteurs et consommateurs de services. La mise en conformité – c’est-à-dire la conversion du format de données interne dans le format canonique – peut être réalisée par chaque sous-système, ou par l’ESB (la première solution a ma préférence, mais ce n’est pas le sujet du moment). Chaque composant est désormais uniquement couplé au modèle canonique, et la figure rassurante du plat de ravioli semble de nouveau à portée de main.

Reste un problème épineux auquel tous ceux qui tentent de mettre en place une architecture orientée services sont potentiellement confrontés : qui définit et maintient le (ou les) modèle(s) canonique(s) ? Les apôtres de l’urbanisation bureaucratique et de la gouvernance centralisée tendent à promouvoir un long et coûteux travail de modélisation transverse en amont. Je crois cette approche fondamentalement erronée : au mieux, elle risque d’aboutir à un report sans fin de la mise en oeuvre ; au pire, elle conduit à la mise en place d’un modèle rigide, excessivement complexe, mal adapté aux besoins réels des applications et hermétique au changement. Incrémentaliste convaincu, je crois au contraire que le modèle canonique doit être construit de façon progressive et collaborative, en prenant en compte les besoins à mesure qu’ils se présentent ; cela suppose que l’architecture intègre les évolutions du modèle canonique – faute de quoi le problème, une nouvelle fois, aura juste été déplacé. Il doit donc être possible de refactorer le modèle canonique – une opération que les ESB, précisément, rendent possible. Mais ceci est une autre histoire…

La complémentarité de Scrum et XP est communément admise. Scrum se positionne au niveau de la gestion et de l’organisation de projet là où XP se positionne au niveau des activités de développement. C’est la raison pour laquelle ces deux approches fonctionnent si bien ensemble : elles adressent des problématiques différentes et se complètent mutuellement.

Je vous propose, dans cet article, une présentation sommaire de Scrum et de la façon dont elle (il? non, allez, c’est plutôt une fille) s’articule avec eXtreme Programming… Bonne lecture !

Scrum

Davantage qu’une méthode formelle, Scrum peut être vu comme un framework méthodologique – ses fondateurs parlent d’organisationnal pattern – dont l’implémentation doit être ajustée en fonction des caractéristiques techniques, organisationnelles et culturelles des projets qui souhaitent la mettre en oeuvre (Scrum, au demeurant, ne limite pas son champ d’application aux seuls projets informatiques : ses principes sont applicables pour toute activité visant à produire un résultat).

Dans ses grandes lignes, Scrum définit un jeu minimal d’acteurs, de cérémonies et d’artefacts qui permettent de relever les défis principaux du développement incrémental : la planification, la gestion du temps et la gestion des obstacles. Scrum est entièrement piloté par la Valeur Métier – la gestion des risques, en particulier, est réalisée au travers de ce prisme. Scrum identifie trois acteurs :

• le Product Owner (Directeur de Produit), qui possède l’expertise fonctionnelle et est à même de réaliser les arbitrages nécessaires à la priorisation des développements. Son rôle est absolument essentiel, et son respect des règles du jeu est la pierre angulaire du succès d’un projet agile.
• le Scrum Master, membre de l’Equipe, et dont la tâche principale est d’optimiser la capacité de production de l’Equipe en l’aidant à travailler de façon autonome et à s’améliorer constamment. Il est également le garant de la bonne implémentation de Scrum.
• l’Equipe, dont la taille doit être réduite (7 à 9 personnes est généralement admis comme une borne supérieure), et qui prend en charge le développement du produit (planification, conception, codage, tests, documentation) sans spécialisation des rôles. La particularité d’une Equipe Scrum est d’être « auto-organisée », et donc dépourvue de hiérarchie. Cet aspect constitue une rupture radicale avec les approches managériales traditionnelles, qui privilégient un contrôle centralisé généralement incarné par le Chef de Projet.

L’unité de temps, dans Scrum, est le Sprint. Un sprint est une itération courte (de l’ordre de 2 à 4 semaines) dont le périmètre est garanti et défini lors d’une cérémonie de planification initiale.

Le schéma suivant décrit l’articulation générale de Scrum :

Scrum définit également trois artefacts (nous conservons les noms anglais pour rester consistant avec la littérature sur le sujet) :

• le Product Backlog, que nous décrivons plus loin
• le Sprint Backlog, également décrit plus loin
• le Burndown Chart, qui est une représentation graphique très simple de l’avancement du projet (un Burndown Chart est produit pour chaque Sprint, un autre pour la version du produit)

Le Product Backlog est fondamental à Scrum – sans lui, rien n’est possible.

Le Product Backlog est la liste des fonctionnalités du logiciel. Les éléments du backlog sont rédigés sous forme de « User Stories » (une User Story est une forme simplifiée et faiblement détaillée de cas d’utilisation), et doivent se focaliser sur les objectifs métier du produit. A minima, un élément du backlog (ou une histoire) comporte typiquement les informations suivantes :

• un identifiant – unique, il permet de tracer l’élément quand on le renomme
• un nom – court et descriptif, suffisamment clair pour que le Directeur de Produit et l’Equipe comprennent approximativement de quoi il est question
• l’importance – un chiffre permettant de hiérarchiser l’importance de l’élément aux yeux du Directeur de Produit. Sa valeur absolue ne signifie rien, seule la valeur relative compte
• l’estimation initiale – exprimée en points de complexité, et dont la valeur est déterminée par l’Equipe. Pour établir cette estimation, on utilise le plus souvent une technique issue de l’eXtreme Programming : le Planning Poker.
• comment faire la démo ? – cela correspond globalement à la spécification d’un test fonctionnel simple.
• des notes – aussi brèves que possible, visant à clarifier certains points ou à renvoyer vers d’autres ressources

Le Product Backlog peut également contenir des éléments techniques – mais il est indispensable alors qu’ils soient libellés selon un angle métier, afin que le Directeur de Produit puisse lui affecter une valeur.

Le Product Backlog peut être conservé sous différentes formes, la plus fréquente – et probablement la plus efficace – étant un simple tableau Excel partagé.

Le Product Backlog n’est pas un document figé : tout au long du projet, les histoires peuvent être modifiées, fusionnées ou segmentées (celles bien sûr qui ne sont pas encore achevées) ; de nouvelles histoires peuvent être ajoutées, d’autres supprimées ; l’importance et l’estimation initiale peuvent être revues, à la hausse ou à la baisse.Au début de chaque Sprint a lieu la cérémonie qui est probablement la plus importante de Scrum : le Sprint Planning (planification du Sprint). Le Sprint Planning réunit l’Equipe et le Directeur de Produit pour déterminer l’objectif et le contenu du Sprint à venir. C’est durant cette cérémonie que l’estimation fine de la charge de développement de chaque histoire est déterminée. Ces histoires sont découpées en tâches dont chacune fait l’objet d’une estimation de charge – exprimée en heures ou en jours. Il est important de noter que c’est l’Equipe qui détermine la charge afférente à chaque tâche. Le principal résultat de cette cérémonie est le Sprint Backlog, qui regroupe l’ensemble des fonctionnalités que l’Equipe s’engage à produire durant l’itération naissante, et liste les tâches correspondantes.

La charge totale du Sprint Backlog ne doit pas excéder la capacité de production de l’Equipe (il existe plusieurs techniques que nous n’aborderons pas ici pour établir cette capacité de production, ou vélocité estimée).

Au terme de chaque sprint, le produit partiel est livré avec le niveau de qualité attendu pour son exploitation en production – cette caractéristique est à l’origine du qualificatif « incrémental » souvent associé aux méthodes agiles. Les histoires implémentées font l’objet d’une démonstration publique.

Les méthodes agiles sont inspirées des pratiques industrielles de la production en flux tendus et du zéro-défaut – un ensemble de pratiques désignées dans l’industrie par le terme Lean. L’une des caractéristiques de cette approche est de ne jamais figer les méthodes de travail, mais d’intégrer dans l’activité une introspection permanente sous-tendue par la recherche systématique d’axes d’amélioration. Une autre caractéristique est de ne jamais utiliser la qualité comme variable d’ajustement. Dans Scrum (et d’une façon générale pour toutes les méthodes agiles), la qualité du produit est de la responsabilité de l’Equipe, et ne fait pas l’objet de négociations.

Afin de faciliter cette démarche, Scrum intègre un certain nombre de cérémonies additionnelles – une cérémonie est une réunion dont la durée est fixée et dont les produits en entrée et en sortie sont définis. La limite de temps pour chacune des cérémonies fait partie de l’ADN de Scrum (on parle de time boxing).

Voici les principales cérémonies préconisées par Scrum :

• le Sprint planning, que nous avons déjà abordé
• la mêlée quotidienne (Daily Scrum), courte cérémonie (de l’ordre de 15 minutes) menée chaque jour avec les membres de l’Equipe et le Directeur de Produit, et dont l’objectif est de maintenir chacun au courant de l’activité de tous, de déterminer les tâches de la journée et d’identifier les éventuels obstacles qui ralentissent ou empêchent la progression du sprint
• la revue de sprint (Sprint Review), qui consiste pour l’essentiel, au terme de chaque itération, à faire une démonstration publique du résultat du sprint ; cette cérémonie permet de garantir le caractère incrémental du développement (pour être démontré, le produit doit être utilisable) mais aussi de recueillir un retour régulier des commanditaires aux fins d’ajuster le contenu du backlog de produit
• la rétrospective (au moins 1 heure), qui réunit l’équipe et le Product Owner au terme de chaque sprint afin d’identifier les erreurs commises lors du sprint précédent et de définir un plan d’actions (concret et affecté) en vue d’améliorer le processus ; la rétrospective est une cérémonie capitale qui incarne l’un des principes fondamentaux énoncés par le Manifeste Agile : « A intervalles réguliers, l’équipe réfléchit sur les moyens de devenir plus efficace, puis adapte et ajuste son comportement en conséquence ».

Une dernière question peut se poser : quels outils utiliser pour assurer le suivi de projet ? Il existe un certain nombre d’offres logicielles dans ce domaine. Dans la pratique, nous préconisons de débuter avec l’outillage le plus élémentaire : une feuille Excel, des post-it et un mur. Avec l’expérience, et en adhérant aux principes généraux de la méthode (inspecter et s’adapter), le Scrum Master pourra choisir d’utiliser d’autres outils. Dans la pratique, une telle démarche n’est que rarement nécessaire.

Scrum, on le voit, adresse la problématique du processus de production du logiciel, l’organisation et la dynamique du projet. Le développement incrémental, néanmoins, suppose des pratiques d’ingénierie logicielle rigoureuses et efficicaces, que Scrum ne couvre pas – rappelons que Scrum est avant tout un style organisationnel. C’est précisément sur ce terrain des techniques de génie logiciel incrémental que l’eXtreme Programming trouve tout son sens, en proposant un certain nombre de pratiques reconnues aujourd’hui comme l’état de l’art.

eXtreme Programming – XP

La première des pratiques de l’eXtreme Programming, la plus fondamentale également, est le test automatisé.

L’approche incrémentale suppose une vision minimaliste – on aurait envie de dire zen – du développement : seules les fonctionnalités effectivement nécessaires sont développées, et le design adopté doit être le plus simple imaginable permettant d’implémenter intégralement la fonctionnalité (ce principe est souvent désigné sous l’acronyme KISS : Keep It Simple and Stupid). Le Manifeste Agile définit au demeurant la simplicité comme « l’art de maximiser le volume de ce qui ne doit pas être fait ». Conséquence de cette recherche de simplicité, certains choix de design, suffisants à un moment donné, peuvent s’avérer inadaptés lors de développements ultérieurs. L’ajustement se fait alors par refactoring (ou ré-ingénierie), qui consiste à modifier le design voire l’architecture d’un composant sans changer son comportement. Le refactoring – une opération techniquement triviale avec les environnements de développement java, plus délicate lorsqu’il s’agit de la base de données – comporte un risque de régression évident, risque couvert en principe par la pratique des tests unitaires. L’équation est alors simple : sans tests unitaires, le refactoring devient rapidement impossible ; sans refactroring, les choix d’implémentation ne peuvent plus être remis en question ; sans remise en question, le développement incrémental devient illusoire, et c’est tout l’édifice du développement agile qui s’écroule.

Le test automatisé n’est pas seulement une bonne pratique du développement agile : il en est l’épine dorsale.

XP inclut la systématisation des tests automatisés – unitaires, fonctionnels, d’intégration, de performance, le plus est le mieux. Poussée à l’extrême, cette pratique a donné naissance au principe du TDD (Test Driven Development). Le TDD modifie sensiblement la pratique du développement. Son principe est d’une redoutable simplicité, mais sa mise en oeuvre est un véritable défi. Voici comment Henrik Kniberg résume le TDD :

Test-driven development means that you write an automated test, then you write just enough code to make that one test pass, then you refactor the code primarily to improve readability and remove duplication. Rinse and repeat.

Traduction : le développeur écrit en premier lieu un test automatisé de la fonctionnalité qu’il souhaite implémenter, développe ensuite juste assez de code pour satisfaire le test et finalement remanie le code pour améliorer le design et supprimer la duplication.

Outre les bénéfices classiques des tests unitaires, le TDD possède deux vertus cardinales : il permet de maintenir le focus du développeur sur les fonctionnalités réellement utiles ; il a des effets spontanés et profonds sur la qualité du design.

Au delà du TDD, XP comprend un certain nombre de pratiques dont la mise en place est souvent associée à l’adoption des méthodes agiles – sans pour autant sue cette mise en place soit obligatoire.
Voici, sans exhaustive, les plus importantes de ces pratiques :

• le Refactoring ; nous l’avons déjà rapidement abordé, c’est une pratique intrinsèque du développement incrémental et qui mériterait un billet à part entière. Pour une bonne introduction aux technique de refactoring objet, je vous invite à consulter le site que Martin Fowler a consacré au sujet : refactoring.com.
• l’Intégration Continue ; cette pratique consiste à déclencher de façon systématique le système de build – qui comprend notamment la compilation et l’exécution des tests automatisés – chaque fois qu’un membre de l’équipe valide des sources dans le référentiel projet ; c’est une pratique essentielle pour détecter et corriger au plus tôt les problèmes d’intégration des développements (principe de fail fast)
• la Propriété Collective ; la propriété collective du code consiste à ne pas spécialiser certains membres de l’équipe sur certains composants – et donc à favoriser la polyvalence au sein de l’équipe. Elle est évidemment favorisée par des pratiques telles que la programmation en binôme qui favorise l’appropriation d’une base commune de code. Les équipes avec un haut niveau d’appropriation collective de code sont réputées pour être plus robustes : un sprint ne sera par exemple pas forcément menacé par l’absence ponctuelle d’un membre de l’équipe.
• les Normes de développement ; sans être une particularité de l’eXtreme Programming, les normes de développement en sont un élément clé, facilitant les tests, l’intégration continue et l’appropriation collective de la base de code. Elles renforcent également la consistance des APIs.
• la Programmation en binôme (Pair Programming), qui consiste à développer à deux sur un même poste ; cette pratique, souvent mal comprise, n’est que rarement systématisée. Il ne faut par contre pas s’interdire son utilisation ponctuelle, par exemple sur une nouvelle technologie, une problématique pointue, un fonctionnel plus complexe, ou plus simplement, si l’un des membres de l’équipe demande de l’assistance. C’est aussi une pratique utile lors des montée en charge de l’équipe : elle permet d’intégrer plus rapidement les nouveaux développeurs et de leur communiquer la culture de l’équipe.
• un Rythme soutenable ; ce principe est commun à toutes les méthodes agiles, et directement issu du heijunka Lean ; il part du principe qu’il n’y a rien de plus contre-productif à moyen terme que de maintenir une équipe de développement sous la pression d’une charge de travail supérieure à sa capacité de production – cela revient à étrangler la poule aux œufs d’or et se traduit généralement par une baisse massive de la qualité et de la motivation.

Certaines des pratiques de l’eXtreme Programming ont irrigué Scrum (ou le contraire, peu importe) : « une équipe », « une même pièce », la notion de « stories », le « rythme soutenable » ou encore le « planning game », raison pour laquelle ces deux approche sont très complémentaires.

Cet article vous a proposé un rapide aperçu de Scrum et XP et aura, je l’espère, contribué à mettre en exergue la complémentarité des deux approches. Beaucoup de notions ont été évoquées de façon trop brève, et je reviendrai dessus dans de prochains billets… N’hésitez pas à laisser vos commentaires et questions !

Le 18 décembre prochain, se tiendront à la Défense les premières Rencontres Agiles.
Il s’agit d’une conférence cosponsorisée par XEBIA, OCTO et SFEIR et dont le principe est d’une simplicité enfantine :

• Une salle de 200 places, inscription gratuite
• Une matinée complète, sans interruption
• Des sessions de 20 minutes pour aller rapidement à l’essentiel (no fluff, just stuff).
• Une sélection des meilleurs acteurs de l’Agile en France aujourd’hui.

Le programme se construit de manière incrémentale – il est publié au fur à mesure sur le site de la conférence. Au menu : une dizaine de sessions couvrant des pratiques, des retours d’expérience et des démonstrations d’outils.
Si vous voulez en savoir le maximum sur l’agilité aujourd’hui en France en une matinée, inscrivez-vous dés maintenant sur le site de la conférence !

Je vous explique.

Le programme consiste à appliquer massivement un traitement identique à un volume important de données – bref, c’est un batch. Objectif opérationnel : assurer la capacité du système à traiter 50000 dossiers par heure.
L’architecture d’exécution de ce batch est relativement classique : un contrôleur est chargé d’obtenir auprès d’un service métier une liste de dossiers à traiter, de segmenter cette liste en lots, puis de soumettre les lots à un pool de threads qui vont réaliser les traitements en parallèle – chaque lot est traité dans une transaction distincte. Le traitement unitaire d’un dossier est relativement long, de l’ordre de 2 secondes ; les lots sont donc petits – 4 dossiers – pour limiter la durée des transactions.

Au-delà de son rôle de segmentation et de répartition des lots, le contrôleur fournit un ensemble de services de pilotage, qui n’ont pas vraiment de relation avec notre problème, mais que je mentionne pour information : état d’avancement du traitement, interruption, reprise, calcul de statistiques variées, rapports d’erreurs, etc.

Typiquement, avec une telle architecture, le débit total du système est une fonction du temps de traitement unitaire et du nombre de threads simultanés :

Débit Horaire = (3600 / Temps Unitaire) * Nombre de threads

Pour mon batch, le calcul théorique est simple : le traitement de chaque dossier demandant 2 secondes, un thread peut traiter 1800 dossiers par heure. Le débit cible étant de 50000 dossiers par heure il est donc théoriquement nécessaire de démarrer un pool de 30 threads.
Ce calcul cependant part d’une hypothèse audacieuse : il suppose que les temps de traitement unitaire resteront stables quel que soit le nombre de threads. En somme, que la montée en charge du système est parfaitement linéaire.

Or les tests grandeur réelle réalisés en pré-production montrent un comportement assez éloigné de notre équation platonicienne :

Exprimé sous forme de débit, ce même graphe montre une pente inquiétante :

Le débit horaire s’écarte de plus en plus de la valeur théorique idéale et tend vers une valeur désespérément éloignée du débit cible. Pire, il aurait tendance à se dégrader lorsque le nombre de threads devient trop élevé. Pas de panique, cependant, ce comportement ne saurait déstabiliser le briscard de la performance que je suis : de telles courbes révèlent simplement que le système atteint une limite qui interdit la montée en charge. Reste à déterminer quel composant physique ou logiciel en est à l’origine.

La première réaction est naturellement de vérifier qu’aucun composant physique n’arrive à saturation. Les outils ad hoc sont utilisés pour contrôler la consommation CPU, l’overhead du GC, le paging, la bande passante, les I/O disque, etc., je vous épargne le détail. Deux éléments intéressants sont tirés de cette analyse : premièrement, aucun composant physique n’approche ses limites de capacité ; deuxièmement, leur niveau de charge épouse presque parfaitement l’évolution du débit présenté dans la figure 2. En d’autres termes, l’usage des ressources physiques, par exemple la charge moyenne des processeurs, présente la même évolution que le débit : leur montée en charge est freinée et s’écarte inexorablement de la progression théorique linéaire.
Une nouvelle fois, ce sont des caractéristiques relativement communes des systèmes parallélisés : cela signifie que les threads d’exécution entrent en compétition pour obtenir certains verrous, ou pour accéder à certaines sections critiques ; plus le nombre de threads augmente et plus la compétition devient serrée : il faut de plus en plus de temps pour acquérir les verrous.

Dans notre système, deux composants sont susceptibles de créer ces conditions :

• la base de données, qui gère des verrous à différents niveaux
• le code java, au travers de blocs synchronisés

Quiconque a déjà travaillé sur un système transactionnel fortement parallélisé sait que les contentions sur la base de données en sont le principal écueil. Pour assurer l’isolation des transactions, les SGBD posent des verrous en lecture et/ou en écriture sur des lignes, des pages ou des tables – en cas de très forte charge, la granularité des verrous est parfois modifiée dynamiquement, passant par exemple de la ligne (ROW LOCK) à la page (PAGE LOCK).
Notre système batch a été conçu en conséquence : la base est partitionnée selon des axes fonctionnels stricts, les opérations de lecture et d’écriture ont été soigneusement séquencées, les verrous sont posés au niveau des pages et le contrôleur sait exploiter certaines caractéristiques du stockage physique pour calculer et répartir les segments entre les différents threads. Une analyse des contentions sur la base de données a démontré l’efficacité de ces stratégies : le niveau de contention reste remarquablement bas, et n’explique en aucun cas la forte dégradation observée lors de la montée en charge.

Reste une seule explication : des contentions dans les couches d’exécution Java. Et une question : comment identifier l’origine de ces contentions, et les corriger ?

Un premier test est réalisé pour valider l’hypothèse de contentions applicatives dans le code java : il consiste à démarrer 5 processus dotés chacun d’un pool de 4 threads – un total de 20 threads, donc, permettant d’atteindre un taux de parallélisation qui dans nos tests précédents mettaient fortement en exergue la dégradation des temps de traitements unitaires. Ce test est concluant : distribués sur 5 processus distincts, les threads ne sont plus soumis à une compétition mortifère, et la montée en charge se réalise de façon satisfaisante.

Une solution envisageable serait d’adopter cette architecture, et de distribuer les traitements sur plusieurs processus. Le contrôleur, cependant, n’a pas été conçu pour coordonner plusieurs processus. L’évolution la plus simple, consistant à séparer le contrôleur des composants métiers – par exemple au moyen d’EJBs – implique d’introduire une couche de distribution qui nous semble d’autant moins souhaitable que le contrôleur est en charge du pilotage des transactions : le séparer des traitements signifie distribuer les transactions, et tous les petits soucis que cette décision implique généralement. Cela signifie aussi probablement l’introduction d’un serveur d’applications dans l’architecture de batch, avec les difficultés afférentes en terme de déploiement et d’exploitation. D’autres évolutions plus massives sont envisageables : par exemple s’appuyer sur des tables techniques pour stocker les segments, et découpler complètement une phase de pré-processing – consistant à calculer les lots – et une phase de traitement – consistant à piocher des lots dans la base et à les traiter. On peut même imaginer des solutions plus exotiques, à base de files JMS… Mais pour tout dire, nous aimons la compacité de notre architecture initiale, et ne sommes pas prêts à l’abandonner sans résister un peu. La question reste donc entière : comment débusquer l’origine de nos contentions aux fins de les liquider ?

L’analyse statique du code n’a rien donné : le contrôleur, à l’instar des composants métiers, utilise un bon zillion de bibliothèques tierces, plus ou moins open source et au flot d’exécution volontiers cryptique. Impossible dans ces conditions de déterminer l’origine exacte des contentions par simple consultation des sources : une analyse runtime est nécessaire.

Reste à trouver le bon outil dans la sacoche du plombier java. Même avec l’aide gracieuse de Google, la récolte reste maigre en matière d’outillage…

Autant l’offre est pléthorique lorsqu’il s’agit de profiler la consommation CPU ou mémoire des applications Java, autant l’analyse des contentions reste une discipline peu outillée. Certes les profilers java offrent pour la plupart un module d’analyse de threads ; mais leur overhead est tel qu’il est difficile, voire impossible d’instrumenter un traitement fortement multi-threadé comme notre batch : au-delà de 3 ou 4 threads, les informations collectées perdent de leur pertinence, et les temps unitaires s’allongent tellement que toute tentative d’analyse relève de l’acrobatie la plus pure.
Tordons rapidement le cou à hprof, le profiler intégré au JDK – le notre, en l’occurrence, est un JDK IBM 1.4.2 SR8 ; la documentation indique une option « monitor=y », qui, je cite, « tells hprof to generate information on contention monitors used to synchronize the work of multiple threads » (je vous laisse traduire). Bigre, nous voilà sauvés ! Pas tout à fait… Outre que le faire fonctionner a demandé une montée de version du JDK – la version que nous utilisions à l’origine générait un très joli core lors de l’activation de hprof -, les informations obtenues se sont révélées d’une rare inutilité (fondamentalement, un état des moniteurs java au moment de la sortie du processus. Aucun intérêt !).
Exit hprof, donc.
Autre approche : générer de façon répétée des Thread Dump à l’aide de l’instruction kill -3, puis comparer les différents dumps à l’aide d’un outil ad hoc (en l’occurrence un utilitaire disponible sur le site alphaWorks, et dont je donne le nom complet pour souligner le sens du marketing des ingénieurs IBM : IBM Thread and Monitor Dump Analyzer for Java Technology). Bien que prometteuse, cette solution n’a une nouvelle fois pas donné de résultat définitif : elle nous a permis d’identifier quelques méthodes candidates, mais sans qu’il fût possible de quantifier leurs responsabilités respectives.

Reste une solution : retrousser ses manches et écrire un profiler spécialisé en s’appuyant sur JVMPI.
JVMPI (pour Java Virtual Machine Profiling Interface) est, comme son nom le suggère, une API native de profilage de la JVM (remplacée par JVMTI à partir de Java 5, mais c’est une autre histoire). L’API fonctionne sur un système de callback : l’agent (c’est ainsi que l’on nomme le programme s’appuyant sur l’API) s’enregistre auprès de la JVM en précisant les types d’événements dont il souhaite être notifié – vous aurez probablement reconnu le pattern Observer.
Ces événements concernent la plupart des opérations techniques de bas niveau réalisées par la JVM : chargement d’une classe, allocation mémoire, exécution d’une méthode, démarrage d’un thread, etc. Parmi ces événements, deux retiennent particulièrement notre attention : MONITOR_CONTENDED_ENTER et MONITOR_CONTENDED_ENTERED. Le premier indique qu’un thread souhaite exécuter un bloc synchronisé, et tente d’acquérir un moniteur à cette fin (pour mémoire, la notion de moniteur en java est très proche de celle de verrou dans le reste du monde); le second indique que le thread a obtenu le moniteur en question et entame l’exécution du bloc synchronisé. L’intervalle de temps entre les deux événements correspond par conséquent à la durée totale de l’attente – autrement dit à la durée de la contention.
Munis de ces rudiments de JVMPI, il est possible de formuler les spécifications exhaustives de notre petit outil de profilage : la durée de toutes les contentions rencontrées par le programme est mesurée. Si cette durée est supérieure à un certain seuil (disons 5 millisecondes), le nom de la méthode correspondante est loggué dans un fichier, ainsi qu’une pile d’appels simplifiée.

Bien. Il ne reste plus qu’à coder.

Le point d’entrée d’un agent JVMPI est la méthode JVM_OnLoad. C’est dans cette méthode que l’on va informer le sous-système JVMPI des événements que l’on souhaite activer (EnableEvent), et de la méthode callback qui sera invoquée lors des occurrences de ces événements (NotifyEvent) :

JNIEXPORT jint JNICALL _JVM_OnLoad(JavaVM *vm, char *options, void *reserved)
{
    ...
    /* Register callback method */
    jvmpi->NotifyEvent = jtprof_notify_event;
    /* Enable events */
    jvmpi->EnableEvent(JVMPI_EVENT_JVM_SHUT_DOWN, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_CLASS_LOAD, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_CLASS_UNLOAD, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_MONITOR_CONTENDED_ENTER, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_MONITOR_CONTENDED_ENTERED, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_THREAD_START, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_THREAD_END, NULL);
    ...
    return JNI_OK;
}

La méthode callback, jtprof_notify_event, se contente de déterminer la nature de l’événement et de déclencher un handler spécialisé :

static void jtprof_notify_event(JVMPI_Event *event)
{
    switch(event->event_type) {
        case JVMPI_EVENT_JVM_SHUT_DOWN:
            handle_jvm_shut_down_event();
            return;
        ...
        case JVMPI_EVENT_THREAD_START:
            handle_thread_started_event(event);
            return;
        case JVMPI_EVENT_THREAD_END:
            handle_thread_end_event(event);
            return;
        case JVMPI_EVENT_MONITOR_CONTENDED_ENTER:
            handle_monitor_contented_enter(event);
            return;
        case JVMPI_EVENT_MONITOR_CONTENDED_ENTERED:
            handle_monitor_contented_entered(event);
            return;
        ...
    }
}

Les choses semblent relativement simples. L’API JVMPI offre même un système de stockage thread local (méthode GetThreadLocalStorage), permettant de conserver une structure de données quelconque dédiée à chaque thread. Je vous épargne les détails de la création et de la destruction de cette structure de données – les curieux pourront jeter un oeil sur le code source. Sachez simplement qu’elle est créée lors de l’événement THREAD_START, détruite lors de l’événement THREAD_END, et qu’elle permet notamment de conserver la date de la demande d’acquisition du moniteur par le thread.

Au final, le code permettant de mesurer la durée d’acquisition d’un moniteur est relativement trivial :

static void handle_monitor_contented_enter(JVMPI_Event *event){
    thread_local_context *ctx = (thread_local_context*)jvmpi->GetThreadLocalStorage(event->env_id);
    //Error handling code
    ....
    ctx->timer = system_current_time_millis();
}
static void handle_monitor_contented_entered(JVMPI_Event *event){
    long finish = system_current_time_millis();
    long total;
    thread_local_context *ctx = (thread_local_context*)jvmpi->GetThreadLocalStorage(event->env_id);
    //Error handling code
    ....
    total = finish – ctx->timer;
    ctx->timer = 0;
    if (total > __contention_threshold){
        //Log contention details
        ....
    }
}

Les choses, bien sûr, sont en réalité un poil plus complexes – fallait pas rêver, non plus.
Par souci d’efficacité, en effet, la structure de données JVMPI_Event ne contient, pour chaque événement, qu’un jeu minimal d’informations. En pratique, cela signifie que le nom de la méthode invoquée n’est pas disponible sous forme littérale, mais sous la forme d’un identifiant interne créé lors du chargement de la classe correspondante.
Logguer cet identifiant ne serait bien sûr pas d’un grand intérêt. Il faut pouvoir l’associer au nom qualifié de la méthode. Pour cela, l’événement CLASS_LOAD doit être traité. Cet événement fournit la définition complète de la classe et de toutes ses méthodes – y compris leur nom littéral. Notre programme conserve donc ces informations dans un tableau associatif (dont le code source est très largement inspiré de celui de hprof). Ce tableau peut ensuite être consulté lors du traitement d’une contention afin de déterminer le nom de la méthode appelante à partir de son identifiant. Une technique similaire est mise en oeuvre pour expliciter la pile d’appels. Je vous laisse consulter le code source pour les détails…

Le programme doit être compilé sous forme de bibliothèque dynamique (extension .dll sous Windows, .so sous Unix), inclu dans le LIB_PATH (ou son équivalent) et intégré à la JVM grâce à l’option -Xrunjtprof (jtprof est le nom donné à la bibliothèque). Voici le type de sorties obtenues :

[JTPROF] Contention report [id=-2002923824,thread=Contention-Thread-4,blocked=305ms]
[JTPROF] Stack trace:
[JTPROF]	 org.test.Contentions.blockABitMore (Contentions.java:36)
[JTPROF]	 org.test.Contentions.run (Contentions.java:25)
[JTPROF]	 java.lang.Thread.run (Thread.java:595)
...
[JTPROF] Thread end [id=-2002912512, name=Contention-Thread-6, duration=1519ms, blocked=1416ms]

Une fois mis au point, cet outil s’est révélé très précieux. Son overhead est très faible – les événements les plus gourmands, comme les sites d’allocation mémoire ou la consommation CPU des méthodes, ne sont pas traités. Il nous a fourni un état très précis du niveau de contention, et de la localisation de celles-ci. Une douzaine de méthodes ont été corrigées (la plupart des contentions étaient de très courte durée – rarement plus de 50ms – mais leur fréquence et leur durée avaient tendance à augmenter).
Au terme de ces optimisations, la courbe des débits se présente comme suit :

Il reste un léger décrochage au-delà de 25 threads, mais cette fois-ci, son origine ne fait pas de doute : notre machine de test est simplement saturée, et la contention, cette fois-ci, porte sur l’accès aux processeurs.

Ceux qui ont suivi depuis le début se souviennent peut-être de l’équation présentée plus haut dans cet article :

Débit Horaire = (3600 / Temps Unitaire) * Nombre de threads

S’ils n’ont pas complètement oublié le programme de mathématiques du Brevet des Collèges, ils auront probablement compris que l’augmentation du nombre de threads n’est pas le seul levier du débit : réduire le temps de traitement unitaire en est un autre. Mais ceci est une autre histoire…

A quoi reconnaît-on un projet wannabe agile ? Le plus souvent à la rupture sémantique qui s’opère entre l’équipe technique, chargée du développement, et la maîtrise d’ouvrage, cliente du développement. Les membres de la première s’évertuent à adopter les signes extérieurs de l’agilité – cycles courts, tests unitaires, intégration continue, contrôle qualité, etc. – quand les seconds ignorent tout des principes du développement itératif et incrémental, et ne voient dans l’organisation du projet qu’une aberration supplémentaire, qu’ils affublent le plus souvent d’un qualificatif d’ordinaire réservé aux maisons de joie : « ce projet, c’est le bordel! ».

Quelques signes permettent d’identifier rapidement le wannabisme agile.

Un projet wannabe agile fonctionne souvent par itérations courtes – d’une durée rarement inférieure au mois, cependant, et plus probablement de l’ordre de 6 à 8 semaines -, mais le contenu des itérations suit un plan précis, établi au préalable. On parle en général de lots. Chaque lot a été précisément circonscrit lors des phases de spécification, et son contenu a été contractualisé au même titre que sa date de livraison. Le démarrage d’un lot de développement est entièrement conditionné par la validation préalable des spécifications détaillées de son contenu, et il n’est pas rare, dans un projet wannabe agile, que la livraison d’un lot subisse certaines avaries : variation imprévue de périmètre, retard de livraison, qualité médiocre attribuée en générale au manque de temps.

L’équipe wannabe agile s’efforce d’utiliser l’outillage nécessaire au développement incrémental : test unitaires (généralement JUnit), tests fonctionnels (Fitness), refactoring, automates de build et d’assemblage (Maven), intégration continue (Hudson), contrôles qualités (CheckStyle, Metrics,etc.)… Mais ses efforts se heurtent très souvent aux contraintes du planning : sous la pression des livraisons, les tests unitaires se raréfient, puis disparaissent. Personne ne comprend plus vraiment à quoi peut bien servir Fitness, dont l’usage est tout bonnement abandonné. L’intégration continue a du mal à fonctionner, et est rapidement ressentie comme une lourdeur inutile. Checkstyle est temporairement désactivé : trop de rouge, on le réactivera quand on aura le temps de faire les corrections… Inéxorablement, le développement accumule une dette technique qui ne sera jamais épongée.

Le chef de projet de l’équipe wannabe agile est sommé, parfois à son corps défendant, de fournir un diagramme de Gantt complet et correctement ajusté sur les 6 prochains mois. Les jalons en sont bien sûr ceux du contrat initial de lotissement. Il utilise pour le bâtir la méthode dite du chausse-pied dont les résultats, bien que farfelus, ont le mérite de satisfaire son management.

Faute d’une organisation adéquate, l’équipe wannabe agile est incapable d’identifier le sponsor fonctionnel (celui que la littérature anglo-saxone désigne sous le nom Product Owner). Dans le meilleur des cas, il est identifié mais inaccessible… La mort dans l’âme (et encore, pas toujours !), elle attend donc la validation définitive des spécifications détaillées avant de démarrer ses développements.

Le projet wannabe agile est en général dysfonctionnel : faute d’un alignement global, compris et accepté de tous, sur les paradigmes du développement itératif et incrémental, l’introduction homéopathique des pratiques agiles risque de passer pour du simple amateurisme ; symétriquement, privé de ses poumons – collaboration étroite avec les utilisateurs, product backlog proprement alimenté, itérations de durée fixe et dont le contenu est déterminé en fonction de la capacité de production de l’équipe, feedback technique et fonctionnel permanent, mesure d’avancement systématique -, le développement wannabe agile est condamné à l’asthme, puis à l’asphyxie.

Que penser du wannabisme agile ? En règle général, les projets wannabe agiles sont le résultat d’une initiative exclusive d’une équipe de développement, voire d’un chef de projet, qui a obtenu l’accord plus ou moins tacite de sa direction. Il cherche à obtenir les fruits du développement incrémental – maîtrise des coûts, qualité de la production, tolérance au changement, adéquation aux besoins – sans bénéficier de l’écosystème indispensable à la réussite d’une telle initiative. Faute de soutien actif de sa hiérarchie et de la collaboration étroite de la maîtrise d’ouvrage, cette initiative est vouée à l’échec – au risque de la décrédibiliser durablement.

La mise en place de Scrum est l’affaire de quelques heures. Mais l’adoption d’une méthode de développement itératif et incrémental nécessite une véritable révolution culturelle dans la gestion de projet informatique, révolution qui déborde largement du cadre étroit de l’équipe de développement : les spécifications détaillées écrites doivent être abandonnées au profit des tests, la communication MOA-MOE doit être décloisonnée, les architectes sur piédestal doivent être mis à terre, les pratiques contractuelles castratrices du développement au forfait doivent être proscrites, le planning doit être ajusté en permanence… C’est à ce prix qu’une véritable pratique de développement agile est accessible. Et à ce prix seulement.

Ce billet, librement traduit de mon excellent collègue indien Vikas Hazrati (billet original sur TheServerSide), vise à présenter comment Xebia réussit à faire fonctionner les projets off-shore en s’appuyant sur les principes du Toyota Manufacturing Process, connu également sous le nom de « Lean ». Nous appelons cette méthodologie « Lean Agile Off-shoring ».

Davantage que des économies de bouts de chandelle, notre objectif, lorsque nous avons fondé notre filiale indienne, était de bénéficier de la somme de talents disponibles en Inde pour développer plus rapidement des logiciels de meilleure qualité. Pour gérer les projets, nous avons choisi d’adopter Scrum en raison des solides compétences que nous possédons dans ce domaine, et des succès que nous avons rencontrés dans la conduite de projet agiles avec Scrum. Les principes du « Toyota Way of Working » – que l’on peut au demeurant appliquer à tout type de développement logiciel – nous ont permis d’ajuster le modèle pour obtenir aujourd’hui un processus de développement mature et doté de mécanismes organiques d’amélioration perpétuelle – en un mot, Lean.

Le projet sur lequel cette méthodologie a été mise au point est la refonte d’un système de traitement automatisé appartenant à une administration centrale hollandaise. Le système traite certaines données salariales en provenance des employeurs et d’autres en provenance du système de taxation sur le revenu. Il valide ces données puis crée automatiquement la déclaration de revenu pour la période considérée. Le système traite 16 millions de transactions par mois, avec un débit d’environ 50 transactions par seconde.

L’équipe était composée de 14 personnes, 6 en Europe, 8 en Inde.

La suite présente un ensemble de principes qui ont émergé de cette expérience, et qui nous permettent aujourd’hui de mener des projets de toute taille avec un niveau de productivité et de qualité qui nous épate nous-mêmes !

Principe #1 – Définir une philosophie à long terme et s’y tenir

Le projet a été démarré avec une idée en tête : il ne serait pas une initiative isolée, mais un laboratoire destiné à asseoir un modèle de développement off-shore hautement productif, stable et reproductible.
Deux principes immuables en ont découlé :

• aucun compromis ne doit être fait, jamais, sur la qualité des développements
• toute l’équipe doit, en permanence, inventer et affiner ses pratiques pour supprimer les pertes de temps et les activités sans valeur ajoutée

Principe #2 – Créer un flot de communication continu

Nous avons décidé d’être agiles dans toutes nos actions, et en conséquence de ne pas suivre un plan défini. Néanmoins, sans plan, il est aisé de s’égarer en chemin. C’est là que l’intégration et la communication continues prennent tout leur sens et jouent un rôle vital.

Nous avons adopté un modèle consistant à envoyer régulièrement des ambassadeurs (Scrum Master ou développeurs) d’un site à l’autre, afin de permettre au contexte client de voyager au-delà des frontières, de renforcer la confiance mutuelle des membres de l’équipe, et d’établir cette culture commune indispensable au succès d’un projet agile.

La communication a également été facilitée par la mise en place d’outils de communication permanents sur les deux sites, visant à la construction d’un véritable « lieu de travail virtuel » – caméras, écrans, micros, tableaux numériques, etc. Parler à un membre de l’équipe distante ne doit guère demander plus d’effort qu’à un collègue local.

Enfin, un seul référentiel de source était partagé par les deux équipes, avec un système d’intégration continue pour permettre la détection – et la correction – immédiate des problèmes.

Principe #3 – Utiliser un système « pull » pour éviter la surproduction

Corollaire du principe précédent, il est indispensable de produire le logiciel conformément aux demandes du commanditaire – le fameux « product backlog » de Scrum ; si le backlog est peu fourni, la durée des itérations est réduite, ou le temps ainsi libéré est consacré au refactoring, à l’amélioration du processus ou des livrables, bref à s’assurer que le client obtient ce qu’il veut, au moment où il le veut, et avec des critères de qualité très élevés.

Principe #4 – Niveler la charge (heijunka)

Toyota parle d’éviter le muda (gaspillage), le muri (personnes surchargées) et le mura (irrégularité).

En gardant en mémoire ces objectifs, les principales sources de gaspillage dans un projet off-shore sont : des fonctionnalités superflues, des spécifications inutilement détaillées, des couches de communication superfétatoires entre l’équipe et le commanditaire, la difficulté à accéder à l’information, des erreurs non détectées par les tests.

Un soin tout particulier a été porté dans la définition du périmètre d’une itération, en ne développant que les cas d’usage connus et sur la base de story cards ne comportant que les détails nécessaires à l’itération en cours. Le code était développé directement à partir de ces story cards, en s’assurant que les développeurs, y compris off-shore, aient un contact direct avec le commanditaire.

Afin de niveler la charge de travail, le sprint backlog (c’est-à-dire la liste des fonctionnalités qui doivent être développées au cours d’une itération) était systématiquement établi en conformité avec la vélocité observée de l’équipe. Il n’y a rien de plus contre-productif à moyen terme que de maintenir une équipe de développement sous la pression d’une charge de travail supérieure à sa capacité de production – cela revient à étrangler la poule aux œufs d’or et se traduit généralement par une baisse massive de la qualité et de la motivation.

Mesurer la vélocité réelle de l’équipe, et prévoir la charge en conséquence, est une activité critique.

Principe #5 – Stopper le développement pour régler les problèmes

Nous avons mis en place une culture dans laquelle le travail est interrompu si un problème survient qui met en péril la qualité de la production.

Lorsque les équipes distantes/locales ont eu le sentiment que leur communication n’était pas satisfaisante, nous avons mis en place une machine de communication continue de chaque côté, dotée de haut-parleurs et de vidéo.

Lorsque les équipes ont déterminé que les revues de sprint ne donnaient pas les résultats attendus, nous les avons interrompues, avons déclenché une séance de brainstorming avec tous les membres de l’équipe, et avons mis en place une nouvelle méthode permettant en particulier de consacrer moins de temps à la revue.

S’il y avait un problème avec l’intégration continue ou les tests de performance, nous réglions le problème avant de poursuivre le développement de fonctionnalités additionnelles.

Quand les testeurs fonctionnels ont manqué de temps pour tester le flot de fonctionnalités développées, nous avons suspendu les développements fonctionnels le temps que l’équipe de test absorbe son trop-plein.

Cette culture a non seulement permis de mettre en place rapidement des contre-mesures, mais a également amené à anticiper certains problèmes et à s’ajuster en conséquence.

Principe # 6 – Standardiser les processus communs

La standardisation est la base de l’amélioration continue ; elle permet de diffuser l’expérience des uns dans la pratique des autres, de responsabiliser les membres des équipes, de promouvoir l’apprentissage organisationnel. Le standard, cependant, n’est jamais gelé : il reste au service des objectifs du projet, et doit être mis en question chaque fois qu’il va à son encontre.

Nous avons mis en place des processus standardisés pour le développement à base de test (TDD), pour la gestion des demandes et la résolution des incidents, pour l’assemblage et pour les tests. En aucun cas, bien sûr, ces processus n’étaient figés : ils étaient aussi agiles et vivants que le reste du projet. Simplement, leur existence permettait de démarrer sur une base stable, et de fournir le socle de la culture de l’équipe – et un point de départ pour les améliorations futures.

Principe #7 – Utiliser des contrôles visuels

Une devise simple : tout doit toujours être visible pour tout le monde dans l’équipe – et cela inclut bien sûr le commanditaire.

Le product backlog, géré dans Jira, était commun aux équipes locales et distantes, de même que les diagrammes de suivi (burn down chart) et les états d’avancement quotidien – le tout ouvert au client. Même transparence pour le système de gestion des bugs, dans lequel le client pouvait d’ailleurs déclarer les incidents d’exploitation. Le système d’intégration continue (Cruise Control) déclenchait un build complet à chaque check-in – avec un retour visuel sur le statut du build et une alarme sonore en cas d’échec du build.

Les murs et tableaux – physiques ou virtuels – comportaient suffisamment d’information visuelle pour que n’importe quel commanditaire puisse prendre connaissance de l’état du projet en moins de 10 minutes.

D’une façon générale, quelques codes visuels simples et partagés sont le meilleur moyen de s’assurer que tout le monde possède un niveau d’information adéquat.

Principe #8 – Utiliser des technologies adaptées à l’équipe et aux processus

Un véritable projet lean possède deux vertus cardinales.

Tout d’abord, il transfert un maximum de tâches et de responsabilités aux développeurs – ce sont eux qui sont chargés de créer la véritable valeur ajoutée du projet ; ensuite, il possède, nous l’avons vu, les boucles de rétroaction permettant de détecter et régler les problèmes le plus tôt possible.

Les individus sont la principale richesse d’un projet agile ; c’est donc à eux de décider et d’adapter la technologie pour qu’elle satisfasse leurs besoins – et non la technologie qui dicte la façon dont les choses doivent être faites. Par exemple, nous avons migré toute la logique de présentation de Struts à Spring MVC par ce que cela faisait plus de sens dans le contexte, et que l’équipe s’était mise d’accord sur cette évolution. Les meilleures décisions techniques sont prises par l’équipe, et non, comme c’est trop souvent le cas, par un panel d’architectes autonomes déconnectés des enjeux du projet.

Principe #9 – Privilégier le leadership interne

Les individus sont, répétons-le, la principale richesse d’un projet.

Dans ce projet off-shore, nous étions décidés à promouvoir les leaders à l’intérieur même de l’équipe. Plutôt que d’engager des scrum masters externes, nous avons donc envoyé certains membres de l’équipe – locale et indienne – suivre une formation de scrum master – et nul besoin de préciser que ce sont eux qui connaissaient le mieux l’équipe et ont su le mieux développer leur leadership dans le respect des autres.

Principe #10 – Développer un esprit d’équipe

Une communication sans tabou, un travail efficace, une faible spécialisation des rôles, un bon salaire, les meilleurs outils et matériels, un environnement de travail agréable, un équilibre vie personnelle – vie professionnelle préservé, un perfectionnement continu, une bonne rotation des responsabilités. Voici quelques uns des éléments qui, mis en œuvre avec intelligence et tact, permettent de créer des équipes ultra-performantes.

Une communication saine entre les différentes localisations est un élément clé du succès dans un projet off-shore. Pour gérer cela nous avons, dès le début du projet, favorisé les visites sur le site pair, afin de créer les relations inter-personnelles nécessaires, et avons par la suite régulièrement réitéré ces échanges afin de maintenir la cohésion – ces voyages, bien sûr, n’avaient pas pour but d’accélérer la production, mais de maintenir un climat sain entre les deux sites.

Les gens sont souvent découragés – ou peu enclins – à poser des questions, à parler des problèmes, à mettre en garde contre des objectifs improbables ou à proposer des alternatives aux propositions faites par leurs supérieurs. Nous avons activement promu une culture du questionnement et de la pro-activité. Une fois que les membres de l’équipe eurent réalisé qu’ils avaient la liberté, et la responsabilité, de prendre des décisions, ils sont devenus des contributeurs actifs, et des co-équipiers remarquables.

Principe #11 – Développer les relations avec partenaires et fournisseurs comme des extensions de votre propre entreprise

Etablir une relation honorable et honnête avec partenaires et fournisseurs est l’un des piliers du Toyota Way of Working.

Nous avons autant que possible suivi ce précepte en ouvrant Wiki et Jira au commanditaire et aux sociétés tierces chargées de développer d’autres modules du même projet. Avantage immédiat, une confiance spontanée dans notre travail : nous n’avions rien à cacher.

Non seulement cette transparence a permis de légitimer notre modèle de développement off-shore, mais elle a également permis d’échanger et d’apprendre de nos partenaires.

Principe #12 – Mettre la main à la pâte !

Il n’y a rien de mieux que de mettre la main à la pâte pour juger de la situation ; nous n’avions donc pas d’analyste fonctionnel dédié, ni d’architecte je-sais-tout (Architectus Matrix) : tout le monde devait coder, et cette activité prenait largement le pas sur toutes les autres. Point.

Principe #13 – Evaluer plusieurs alternatives face à un problème, puis implémenter rapidement celle qui a été choisie

Nous avons systématiquement considéré et évalué plusieurs solutions à un problème donné avant d’en choisir une – au besoin au travers d’expérimentations limitées dans le temps ; une fois déterminée la solution appropriée elle était adoptée rapidement et de façon consistante.

Cette approche a pu être mise en œuvre pour toutes sortes de difficultés, dans toutes sortes de domaines : traduction des documents, organisation des journées – il y a 4 heures de décalage entre l’Europe et l’Inde -, choix de bibliothèques ou d’APIs, etc.

Principe #14 – Devenir une organisation apprenante grâce à l’introspection permanente (hansei) et à l’amélioration continue (kaizen)

C’est le principe le plus important, celui qui pilote tous les autres : nous réalisons une évaluation rigoureuse de chaque itération afin de déterminer ce qui fonctionne bien et ce qui pourrait être amélioré – et comment l’améliorer. Chaque itération est ainsi plus mature et plus efficace que la précédente.

Nous sollicitons l’avis immédiat du client et de l’équipe afin que tout dysfonctionnement soit corrigé sans délai, et qu’aucun problème ne s’installe durablement.

En guise d’astuce, pour chaque problème que nous rencontrons, nous recherchons la cause première en posant cinq fois la question « Pourquoi ? ».

Conclusion

Nous continuons, chaque jour, d’apprendre et d’améliorer. La métaphore du développement lean a été appliquée avec succès au développement off-shore. Les principes de Toyota, appliqués au développement logiciel off-shore, offrent un véritable pont vers l’hyper-productivité et la haute qualité.

Cette vidéo traite des numéros :

• 04 : Les bibliothèques tierces
• 03 : Mauvais usage de la concurrence

Cette vidéo traite des numéros :

• 06 : Utilisation impropre des caches
• 05 : Utilisation excessive de la mémoire

Cette vidéo traite des numéros :

• 08 : Usage incorrect de Java EE
• 07 : Utilisation abusive du XML

Cette vidéo traite des numéros :

• 10 : Logging excessif
• 09 : Mauvaise configuration du serveur d’application

La définition la plus répandue des closures est la suivante (Neal Gafter fournit un historique des closures dans son blog [en]) :

A closure is a function that captures the bindings of free variables in its lexical context.

En substance, une closure est un bloc de code référençable, manipulant optionnellement des variables dites « libres » – libres en ce sens qu’elles sont définies non dans le bloc de code, ni de façon globale, mais par le contexte dans lequel le bloc est exécuté.

Un peu de code valant souvent mieux qu’un long discours, voici un exemple très simple d’utilisation des closures en Ruby (Ruby fait un usage intensif des closures, ce qui est probablement à l’origine de l’affection que lui porte ses utilisateurs). Cet exemple est tiré de l’article de Martin Fowler sur le sujet [en].

Imaginons que vous souhaitiez extraire d’une liste d’employés une sous-liste comprenant uniquement ceux qui sont cadres. Une implémentation possible en java est la suivante :

public static List<Employee> managers(List<Employee> employees) {
  List<Employee> result = new ArrayList<Employee>();
  for (Employee e : employees)
    if (e.isManager) result.add(e);
  return result;
}

En Ruby, la même fonction serait codée de la sorte :

def managers(employees)
  return employees.select {|e| e.isManager}
end

La méthode select est définie dans la classe Collection de Ruby. Elle prend en paramètre un bloc de code – la fameuse closure – , défini entre accolades. Si le bloc de code prend des arguments, ces derniers sont déclarés entre deux barres verticales (ce sont les variables « libres », dont la portée est définie par le contexte). La méthode select encapsule l’algorithmique : itération sur la collection, exécution du bloc de code pour chaque élément et construction d’une sous-liste contenant les éléments pour lesquels le bloc de code s’évalue à true.

Il existe bien sûr en Java un mécanisme assez similaire, autorisé par l’usage de classes anonymes imbriquées (Anonymous Inner Class, ou AIC).
Supposons que la classe List possède, symétriquement à sa contre-partie Ruby, une méthode select, prenant en paramètre une interface définie comme suit :

interface Filter<T>(){
  public boolean accept(T e);
}

Alors le code java pourrait s’écrire comme suit :

public static List<Employee> managers(List<Employee> employees) {
  return employees.select(
    new Filter<Employee> {
      public boolean accept(Employee e){
        return e.isManager();
      }
    }
  );
}

Les AIC sont l’avatar traditionnel des closures en java. Les API du JDK en font largement usage (pensez aux interfaces Runnable, Comparable, Callable ou TimerTask, qui fournissent des closures aux classes Thread ou Executor, ou encore permettent de configurer les collections). Les Design Patterns callbacks, factories, predicates ou stategies sont des candidats naturels à ce type de construction. Spring, en particulier dans son framework de templates, les exploite à très bon escient pour masquer le caractère fastidieux de certaines API, JDBC en particulier.

Pour autant, la programmation par closures, très répandue chez les rubyistes, est quasiment inexistante chez les programmeurs java. Le listing ci-dessus fournit une première explication : la syntaxe des AIC, verbeuse à souhait, est propre à décourager les meilleures intentions. Ensuite, le support des AIC dans Java comme mécanisme de closures souffre de sévères limitations : une fois instanciée, une AIC est un objet à part entière, doté d’une portée qui lui est propre, et partiellement aveugle au contexte qui l’a créé. En conséquence, les variables ou méthodes sont résolues dans le portée de ce nouvel objet.

Examinons, pour illustrer ces quelques lignes de Ruby :

i = 1;
1.upto(100) { |num| i *= num; }
puts i;

Ce code permet d’afficher le factoriel de 100. La variable i est définie en dehors de la closure et modifiée dans son corps. Le code java équivalent ne compilerait pas (à supposer qu’une API similaire soit disponible). En effet, pour qu’une variable externe soit accédée dans le corps d’une AIC, elle doit être déclarée final (la raison sous-jacente est que la variable est copiée dans le contexte de l’AIC). Elle ne peut donc être modifiée. Cela ne pose pas de difficulté si la variable est d’un type mutable (comme une liste ou un wrapper), mais peut se révéler problématique s’il s’agit d’un type immutable ou d’un value type (en particulier les String et les types primaires).

Voici un exemple type des contorsions nécessaires en java pour contourner cette contrainte :

final int[] numCompares = new int[1];
Arrays.sort(a, new Comparator<Integer>() {
  public int compare(Integer i1, Integer i2) {
    numCompares[0]++;
    return i1.compareTo(i2);
  }
});
System.out.println(numCompares[0]);

C’est sur ce constat primordial que la proposition CICE a vu le jour. Son objet n’est pas d’altérer le langage java mais de rendre plus concise la syntaxe de création des AIC (en fait, un sous-ensemble de ces dernières, appelées single-abstract-method-types ou SAM, qui sont en substance des interfaces ne comprenant qu’une unique méthode).

Avec la syntaxe proposée par CICE, notre exemple initial serait réécrit de la sorte :

public static List<Employee> managers(List<Employee> employees) {
  return employees.select(
    Filter<Employee> { return element.isManager();}
  );
}

Cette syntaxe dite concise est complétée par une altération des règles d’accès aux variables locales du bloc appelant (en particulier, celles déclarées explicitement publiques peuvent être assignées dans le corps de l’AIC).

Cette approche a bien sûr le mérite de la simplicité puisqu’ellle n’introduit aucun nouveau concept et ne nécessite pas la réécriture des API existantes ; elle pourrait de surcroît probablement être implémentée à l’aide d’une modification mineure du compilateur.

Pour certains, cependant, l’approche CICE ne fait qu’effleurer le sujet et ne propose qu’une mise à disposition minimaliste des closures en Java.

En effet, d’une façon générale, les AIC rompent le contexte d’exécution du code appelant et ne permettent pas de conserver la sémantique d’un nombre important de structures syntaxiques (celles que Neal Gafter appelle « lexically scoped language constructs ») :

• noms des variables
• noms des méthodes
• noms des types
• signification de this
• noms des labels
• référent d’une instruction break sans label
• référent d’une instruction continue sans label
• checked exceptions déclarées ou interceptées
• référent d’une instruction return
• et quelques autres plus exotiques (état d’assignation des variables, reachability, …)

La proposition BGGA est une extension du langage java permettant la mise en oeuvre des closures sans rupture de transparence. La syntaxe proposée par BGGA est loin d’être triviale, ce qui lui vaut de nombreuses critiques – ses contempteurs sont au demeurant souvent les partisans de CICE.

Sans entrer dans le détail (qui peut être consulté sur le site http://www.javac.info/), on retiendra les caractéristiques suivantes :

• BGGA définit une syntaxe permettant de déclarer des closures littérales ressemblant à ça :

  {int x, int y > x+y}
  

• BGGA définit également le concept des function type, dans lequel une fonction possède une liste d’arguments, un type de retour et une clause throws ; on peut instancier un function type à l’aide d’une closure littérale compatible
• la transparence lexicale est intégralement garantie, tant pour l’association de variables que pour la résolution de noms ou les structures de contrôle (break, continue, return) – certaines closures peuvent cependant être marquées restricted et se comporter de façon identiques aux AIC
• BGGA propose une grammaire simplifiée permettant d’exploiter les closures selon une syntaxe très proche de celle des structures de contrôle natives du langage – avec une telle syntaxe, la modification du langage pour introduire la seconde forme de boucle for aurait été superflue

Avec BGGA, l’algorithme suivant

lock.lock();
try {
  ++counter;
}
finally {
  lock.unlock();
}

deviendrait

withLock(lock, {=>
  ++counter;
});

dans la forme canonique et, dans la forme simplifiée :

withLock(lock) {
  ++counter;
}

Notre exemple initial pourrait être codé de la sorte (pour peu que l’API de Collection java se dote d’une méthode select appropriée) :

public static List<Employee> managers(List<Employee> employees) {
  return employees.select({Employee e => e.isManager()});
}

Comme évoqué plus haut, la médaille a un revers. Si côté client l’utilisation des closures BGGA semble relativement simple, la syntaxe risque de considérablement complexifier les API du JDK ou des frameworks désireux d’en tirer parti. Pour se donner une idée, voici le code de la fonction withLock utilisée plus haut :

public static <T,throws E extends Exception>
T withLock(Lock lock, {=>T throws E} block) throws E {
  lock.lock();
  try {
    return block.invoke();
  } finally {
    lock.unlock();
  }
}

A l’instar des génériques, qui ont rendu presqu’illisible au commun le code source de certaines classes du JDK, une telle évolution syntaxique risque de dresser une barrière supplémentaire à l’apprentissage du langage java, et creuser encore davantage le fossé entre l’utilisateur d’API (Joe Java, comme disent certains) et le concepteur d’API. Le jeu en vaut-il la chandelle ?

Références (toutes en anglais) :
[1] La proposition BGGA, présentée par Neal Gafter aux Google TechTalks
[2] L’approche CICE
[3] Un très intéressant échange sur le site de Crazy Bob, partisan de CICE
[4] Deux articles parus sur developerWorks, le premier sur les closures en général, et le second plus spécifiquement sur le débat BGGA vs CICE.
[5] Un article plus ancien, sur l’approche traditionnelle des closures en java ]]> http://blog.xebia.fr/2007/05/10/des-closures-en-java/feed/ 9 http://blog.xebia.fr/2007/04/11/codez-comme-des-filles/ http://blog.xebia.fr/2007/04/11/codez-comme-des-filles/#comments Wed, 11 Apr 2007 08:11:36 +0000 Guillaume Bodet http://blog.xebia.fr/2007/04/11/codez-comme-des-filles/ Vous avez sûrement déjà , au moins une fois, en parcourant les sources d’un logiciel open source été impressionné par la qualité formelle du code : nommage efficace et pertinent, choix judicieux des paquets et de leur hiérarchie, émergence des concepts au travers de la structure, javadoc riche et dénuée de fautes d’orthographe… même si j’embellis un peu le tableau pour les besoins du propos, on oublierait pour un peu qu’il s’agit du même language que celui utilisé pour développer ce logiciel de gestion aux sources cryptiques dont vous avez hérité la maintenance. En fait, le code source de certains projets open source évoque fortement les fiches bristol que les filles confectionnaient au lycée pour simplifier leurs révisions, vous vous souvenez ? Ces précieuses fiches dont, pour tout dire, vous vous moquiez un peu, mais qui rendaient limpides les cours du semestre précédent quand vous même n’arriviez plus à relire vos propres notes. Jamais vu un garçon faire des fiches bristol bariolées. C’est un truc génétique, je crois, une séquence codante dans la branche manquante du chromosome Y, qui interdit aux mâles l’usage de l’encre turquoise et celle de la règle pour souligner les titres.

La coloration syntaxique et le formattage automatique des sources proposés par les IDE modernes permettent bien sûr, à peu de frais, de donner au code java l’apparence formelle des fiches bristol (ce qui, au passage, devrait les réhabiliter définitivement et couvrir de honte rétrospectives les anciens moqueurs). Mais ce travail d’enluminure textuelle n’est que rarement suffisant pour masquer la faiblesse des choix de nommage ou l’insuffisance des commentaires – quand ce n’est pas l’indigence des concepts architecturaux. Pire : il les met en exergue.

Laissé à lui-même, le développeur mâle standard tend à se laisser aller à une négligence peccamineuse, proche dans le principe de la façon dont il prenait ses notes au lycée, et qui transforme rapidement le code source le mieux intentionné en jachère sémantique – et en cauchemar esthétique. Etant moi même l’auteur de certaines des lignes de codes les plus vilaines jamais produites dans l’hémisphère nord (il m’arrive de faire du Perl), je m’interroge : pourquoi les développeurs open source (du moins certains) échappent-il à la malédiction ?

La raison en est probablement très simple : lorsque l’on développe du code open source, on s’expose à ce que les sources soient consultées par un nombre indéterminé de pairs à l’oeil expert, dont le jugement critique fera ou défera le succès du projet. Alors on tente de produire le plus beau code possible. On renomme 6 fois cette variable. On élague par refactoring. On épure l’architecture. On formatte la javadoc, un espace ici, un saut de ligne là , et là une liste à puces… Bref, on code comme une fille. C’est une bête question d’orgueil, la soif ancestrale de reconnaissance, le besoin de séduire.

Il resterait, bien sûr, à tenter de trouver une définition un tant soit peu opérationnelle de ce qu’est du beau code ; je ne m’y essaierai pas : les philosophes s’étripent (symboliquement, bien sûr, ce sont des gens d’une extrême mesure) depuis des siècles pour définir le Beau, et les programmeurs leur ont, à leur modeste échelle, emboité le pas [1]. Ce qui est sûr, c’est que la plupart des développeurs ont un jugement très sûr et savent reconnaître le beau code quand ils viennent à le croiser (ils utilisent le plus souvent le qualificatif d’élégant pour le désigner). Il arrive même à certains d’en produire… Et s’il est une vertu que chacun s’accorde à trouver au beau code, c’est qu’il est facile à comprendre, à maintenir et à utiliser. Des caractéristiques constitutives d’un logiciel de qualité.

Certaines pratiques clés de l’eXtreme Programming, en particulier le pair programming ou les revues de code systématiques ont pour vocation de stimuler en permanence l’orgueil esthétique des programmeurs en soumettant leur production au regard critique de leurs pairs. Ce n’est pas pour plomber la productivit des codeurs. C’est pour qu’ils produisent du beau code. C’est pour qu’ils codent comme des filles !

Comme son titre le suggère, ce premier billet concerne la journalisation, connue également sous son sobriquet anglo-saxon de « log ».
Depuis plusieurs années maintenant, l’utilisation d’un framework dédié pour gérer les logs s’est généralisée. Log4j a ouvert la voie, suivi par framework java.util.logging à partir du JDK 1.4, qui adopte une architecture très similaire à celle de log4j, tout en proposant une nomenclature moins intuitive (du moins pour ceux qui pensent que « DEBUG » désigne un niveau de journalisation plus évident que « FINEST »). Citons également les meta-frameworks Commons Logging et SLF4J, qui offrent une couche d’adaptation au dessus des différents frameworks pour en unifier l’usage.

L’objet ici n’est pas de comparer ces différentes solutions : elles sont toutes très proches et offrent toutes les fonctionnalités attendues d’un utilitaire de logging:

• une API simple et intuitive, style log.debug(message) ou log.info(message)
• une configuration externalisée permettant d’activer ou de désactiver certaines traces sans intervention sur les sources ou les binaires
• la possibilité de configurer des flux de sortie divers pour les messages (console, fichiers avec rotation, sockets, base de données, JMS, syslog, NTEventLog, etc.), avec une granularité très fine
• la possibilité de configurer le format des messages

On ne peut que se féliciter de l’adoption massive de ces frameworks, en particulier du plus illustre d’entre eux, log4j. Cette adoption a pourtant bien souvent un revers: disposer de ces fonctionnalités a exempté les architectes et développeurs d’une réflexion réelle sur l’usage des logs. La politique de journalisation se réduit fréquemment à cette simple directive : « Utiliser log4j », et le code est en conséquence saupoudré plus ou moins densément (selon l’humeur ou la sensibilité du développeur) d’instructions du style

Logger log = Logger.getLogger(this.getClass());
	[...]
	log.debug("Avant call gloubiboulga casimir.isHeureux()=" + casimir.isHeureux());
	casimir.gloubiboulga();
	log.debug("Après call gloubiboulga casimir.isHeureux()=" + casimir.isHeureux());
	[...]
	catch (Exception ex){
	    log.error("Une erreur s'est produite", ex);
	    throw new RealBadThingHappenedException(ex);
	}
	[...]

Plusieurs problèmes dans cette approche:

• le logger utilisé porte le nom de la classe. Il doit être configuré comme tel (y compris avec les mécanisme d’héritage). Les noms de classe (et de package) n’ont pas vraiment de sens pour les équipes d’exploitation, ce qui limite souvent leur autonomie sur la configuration des traces.
• les messages de debug manquent de consistance, et n’ont de véritable intérêt que pour le développeur au moment de la mise au point de la classe concernée (ce qui, notons-le, n’est pas critique; par nature, les messages de déboguage ne sont pas destinés aux exploitants).
• si plusieurs threads exécutent simultanément la méthode, les traces seront entrelacées et il sera difficile de rétablir le séquencement des opérations
• le message d’erreur est laconique et la pile d’appel, pour utile qu’elle soit, n’est interprétable que par l’ingénierie.
• il n’y a pas de trace intermédiaire entre DEBUG et ERROR, ce qui limite la capacité de diagnostic en exploitation
• l’utilisation des API de log tel quel peut poser des problèmes de performance (cf ce billet)

Nous nous pencherons aujourd’hui sur le problème de la corrélation: dans un environnement multithreadé et distribué, comment relier entre eux les messages relatifs à une même interaction?

Corréler les logs

Dans un environnement multi-threadé, et a fortiori dans un environnement distribué, il est difficile, sinon impossible, de corréler l’ensemble des traces issues d’un même traitement ou d’une même interaction (que l’on nommera désormais transaction pour plus de clareté). La solution proposée par log4j pour adresser ce problème consiste à placer dans chaque message un identifiant de corrélation unique pour chaque transaction. On trouvera une description de ce principe dans « Patterns for Logging Diagnostic Messages »(1).
Log4j supporte nativement cette contextualisation, aux travers des classes org.apache.log4j.NDC et org.apache.log4j.MDC (ce n’est pas le cas de java.util.logging; l’extension de java.util.logging pour supporter les NDC serait néanmoins très simple).
Pour implémenter ce mécanisme, il suffit donc d’intercepter le point d’entrée du système et de fixer l’identifiant de correlation dans le MDC (ou le NDC).
Le cas le plus simple est celui d’une application web, pour laquelle cette interception se fait au moyen d’un filtre:

public class Log4jMDCServletFilter implements Filter {
	public void doFilter(ServletRequest request,
						 ServletResponse response,
						 FilterChain chain)
					throws IOException, ServletException {
		try {
			if (MDC.get("CorrelationID") == null)
				MDC.put("CorrelationID", JOTUtils.generateCorrelationID());
			chain.doFilter(request, response);
		}
		finally {
			MDC.remove("CorrelationID");
		}
	}
...
}

Il suffit ensuite d’utiliser le pattern (cf. org.apache.log4j.PatternLayout) suivant pour disposer systématiquement dans les messages d’un identifiant de correlation :

%d{ISO8601} [%t] %-5p %c %X{CorrelationID} - %m\n

Il est bien sûr possible de fournir un contexte plus riche (par exemple le nom de l’utilisateur, le use case, le service, etc.), et ce mécanisme peut servir de base à un filtrage, permettant d’augmenter le niveau de trace uniquement pour un sous-ensemble de clients ou de contextes.
Le composant NDC (pour Nested Diagnostic Context) permet quant à lui de gérer une pile de contextes imbriqués.

Néanmoins, MDC et NDC s’appuie sur des variables ThreadLocal, limitées donc à l’espace mémoire de la JVM. Les choses se compliquent donc singulièrement lorsque les interactions sont distribuées et que l’on souhaite corréler les traces aux travers de plusieurs JVMs.

Dans un contexte distribué, l’identifiant de correlation doit être propagé aux différents composants traversés. Il n’existe malheureusement pas de moyen universel de réaliser cette propagation : elle dépend du protocole utilisé pour réaliser les invocations distantes. Le plus souvent, cependant, la distribution se fera au moyen de RMI/IIOP.
Le protocole IIOP bénéficie d’une technologie standard d’interception: les PortableInterceptors CORBA. Voici donc un moyen de réaliser la propagation transaparente de l’identifiant de corrélation sur IIOP.

Premier élément, un intercepteur client chargé d’enrichir le flux IIOP d’un contexte spécifique portant l’identifiant de corrélation:

...
public class CORBAClientInterceptor
	extends org.omg.CORBA.LocalObject
	implements ClientRequestInterceptor {
	private org.omg.PortableInterceptor.ORBInitInfo info;
	private int t_slot;
	private static final long serialVersionUID = -6768740178708556025L;
	public CORBAClientInterceptor(ORBInitInfo info, int t_slot) {
		this.info = info;
		this.t_slot = t_slot;
	}
	public String name() {
		return "JOT Log correlation id propagation - Client Interceptor";
	}
	public void send_request(ClientRequestInfo ri) throws ForwardRequest {
		org.omg.CORBA.Any any = null;
		try {
			any = ri.get_slot(t_slot);
		}
		catch (org.omg.PortableInterceptor.InvalidSlot is) {
			throw new org.omg.CORBA.INTERNAL("JOTClientInterceptor : Invalid slot : " + is.getMessage());
		}
		if ( ( any.type().kind().value() == org.omg.CORBA.TCKind._tk_null ) ||
		     ( any.type().kind().value() == org.omg.CORBA.TCKind._tk_void ) )
			return;
		org.omg.IOP.ServiceContext serviceCtx = new org.omg.IOP.ServiceContext();
		serviceCtx.context_id = 995;
		try {
			serviceCtx.context_data = ((String)MDC.get("CorrelationID")).getBytes("UTF-8");
		} catch (UnsupportedEncodingException e) {
			throw new org.omg.CORBA.INTERNAL("JOTClientInterceptor : UTF-8 Not Supported : " + e.getMessage());
		}
		ri.add_request_service_context(serviceCtx, true);
	}
...
}

Il faut ensuite un intercepteur symétrique, côté serveur, chargé de décoder l’identifiant de corrélation et de le placer dans le NDC log4j:

...
public class CORBAServerInterceptor extends LocalObject implements
		ServerRequestInterceptor {
	private static final long serialVersionUID = -5574812890862607150L;
	private org.omg.PortableInterceptor.ORBInitInfo info;
	private int t_slot;
	public CORBAServerInterceptor(ORBInitInfo info, int t_slot) {
		this.info = info;
		this.t_slot = t_slot;
	}
	public String name() {
		return "JOT Log correlation id propagation - Server Interceptor";
	}
	public void receive_request_service_contexts(ServerRequestInfo ri)
			throws ForwardRequest {
		org.omg.IOP.ServiceContext serviceCtx = null;
		try
		{
			serviceCtx = ri.get_request_service_context(995);
		}
		catch (org.omg.CORBA.BAD_PARAM bp){
			//Le client n'a pas fourni de contexte, on en génère un
			MDC.put("CorrelationID", JOTUtils.generateTID());
			return;
		}
		try {
			MDC.put("CorrelationID", new String(serviceCtx.context_data, "UTF-8"));
		} catch (UnsupportedEncodingException e) {
			throw new org.omg.CORBA.INTERNAL("JOTServerInterceptor : UTF-8 Not Supported : " + e.getMessage());
		}
	}
...
}

Et voici la classe d’initialisation qui permet d’enregistrer les intercepteurs:

...
public class CORBAInitializer extends org.omg.CORBA.LocalObject implements
		ORBInitializer {
	/**
	 * Log correlation slot id
	 */
	private int t_slot;
	/**
	 * Pre initialization
	 */
	public void pre_init(org.omg.PortableInterceptor.ORBInitInfo info) {
		t_slot = info.allocate_slot_id();
		CORBAClientInterceptor clientInterceptor = new CORBAClientInterceptor(
				info, t_slot);
		try {
			info.add_client_request_interceptor(clientInterceptor);
			// info.add_server_request_interceptor(serverInterceptor);
		} catch (org.omg.PortableInterceptor.ORBInitInfoPackage.DuplicateName dn) {
			String msg = "Error in initializer: Duplicate name when adding the interceptor : "
					+ dn.getMessage();
			throw new org.omg.CORBA.INTERNAL(msg);
		}
	}
	public void post_init(ORBInitInfo info) {
	}
}

L’implémentation de ce mécanisme pour d’autres protocoles dépend bien sût des capacités de ce protocole. Si le protocole est HTTP, il est assez simple d’ajouter les entêtes adéquates dans les requêtes. Pour d’autres protocoles, les choses peuvent s’avérer plus difficile, voire impossible pour des protocoles propriétaires.

Dans le prochain billet, nous chercherons à centraliser la configuration des catégories et à en simplifier l’usage.

Références
(1) « Patterns for Logging Diagnostic Messages » dans « Pattern Languages of Program Design 3″, édité par R. Martin, D. Riehle, et F. Buschmann (Addison-Wesley, 1997).