La confÃ©rence ACCU 2008

Didier Trosset

Cet article rÃ©sume la confÃ©rence ACCU 2008. Les sÃ©ances traitent des sujets liÃ©s au dÃ©veloppement logiciel : conception, mÃ©thodes, langages, programmation ...

- Titre : La confÃ©rence ACCU 2008

- Auteur : Didier Trosset

- Parution : 24 septembre 2008

- Licence : Ce document est issu de http://www.developpez.com et reste la propriÃ©tÃ© exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise Ã  l'obtention prÃ©alable de l'authorisation de l'auteur.

Sommaire

- La confÃ©rence ACCU 2008

- Mercredi 2 avril

- Tom GilbÂ : Â«Â Mesurer la valeur ajoutÃ©e dans les environnements AgileÂ Â»

- Gail OlisÂ : Â«Â Le PÃ¨re-NoÃ«l et autres mÃ©thodologiesÂ Â»

- Mike Hill, Giovanni AsproniÂ : Â«Â Outils, environnements et librairiesÂ : Å“uvre diabolique ou manne cÃ©leste ?Â Â»

- Pete GoodlifeÂ : Â«Â Histoire de deux systÃ¨mesÂ Â»

- Jeudi 3 avril

- Simon Peyton JonesÂ : Â«Â Contenir les consÃ©quences du monstre : le dÃ©fi de la prochaine dÃ©cÃ©nie.Â Â»

- Kevlin HenneyÂ : Â«Â L'objet Ã©goÃ¯steÂ Â»

- Kevlin Henney, Peter Sommerlad, Giovanni AsproniÂ v: Â«Â DÃ©crypter la simplicitÃ©Â Â»

- Andrei AlexandrescuÂ : Â«Â L'allocation mÃ©moire : l'aimer ou la dÃ©tester (ou penser que c'est trÃ¨s bien comme cela)Â Â»

- Vendredi 4 avril

- Andrei AlexandrescuÂ : Â«Â Puissiez-vous vivre une Ã©poque intÃ©ressanteÂ Â»

- Allan KellyÂ : Â«Â Les managers : Ã€ quoi sont-ils bons ?Â Â»

- Tom GilbÂ : Â«Â Concevoir l'adaptation et la maintenance par l'ingÃ©nierie logicielle : une approche quantifiÃ©eÂ Â»

- Jim Hague, Russel WinderÂ : Â«Â DistribuÃ© ou non distribuÃ©, ou comment connaitre votre SCVD Ã  partir de votre SCVÂ Â»

- Samedi 5 avril

- Roger OrrÂ : Â«Â Les sept pÃªchÃ©s capitaux du debuggageÂ Â»

- James CoplienÂ : Â«Â Les rÃ©ponses Ã  cinq mythes AgileÂ Â»

- Didier VernaÂ : Â«Â Performance et gÃ©nÃ©ricitÃ© : le pouvoir oubliÃ© du LispÂ Â»

- DiffÃ©rents invitÃ©sÂ : Â«Â Ã‰tat des lieux de la professionÂ Â»

- Pour finir ...

La confÃ©rence ACCU 2008

L'ACCU est une association de Grande Bretagne. Elle rassemble des programmeurs qui s'intÃ©ressent Ã  la programmation. Le but de l'association est d'Ã©lever les standards de programmation. Ceci est rÃ©sumÃ© dans le sous-titre "Professionalism in Programming", que l'on peut traduire par "La programmation de haute qualitÃ©"

La confÃ©rence annuelle de l'ACCU a eu lieu en 2008 du 2 au 5 avril Ã  Oxford en Angleterre. Comme ces derniÃ¨res annÃ©es, j'ai eu la chance de pouvoir y participer. Voici donc toute une sÃ©rie de petits rÃ©sumÃ©s et commentaires des sÃ©ances auxquelles j'ai pu assister.

Mercredi 2 avril

Tom GilbÂ : Â«Â Mesurer la valeur ajoutÃ©e dans les environnements AgileÂ Â»

La keynote du jour "Value delivery for Agile environments" est prÃ©sentÃ©e par Tom Gilb, un pionnier des mÃ©thodes de dÃ©veloppement itÃ©ratives. Il a Ã©tÃ© la source d'inspiration de nombreuses mÃ©thodes Agile.

Il nous a prÃ©sentÃ© sa mÃ©thode, basÃ©e sur SCRUM. Ce qu'il reproche aux mÃ©thodes Agile : c'est leur manque de mesure de valeur. Selon lui, le burn rate ne sert Ã  rien pour apprÃ©hender la valeur ajoutÃ©e que va obtenir l'utilisateur final. Il cherche Ã  tout quantifier. Y compris par exemple, la robustesse (qu'Ã  la rÃ©flexion je serai bien en peine de mesurer) ou d'autres qualitÃ©s trop gÃ©nÃ©rales afin de pouvoir leur affecter un coÃ»t et une incidence sur d'autres mesures du projet.

Il crÃ©e avec ceci des tableaux d'estimation d'incidence qui permettent de mieux cibler les travaux Ã  entreprendre afin de dÃ©livrer le maximum de valeur ajoutÃ©e Ã  toutes les parties prenantes (stakeholders) au moindre coÃ»t.

Je suis restÃ© sceptique par le travail Ã  accomplir, qui fait ressembler toute cette Ã©tude prÃ©alable Ã  un bon vieux gros waterfall. Et les commentaires des autres orateurs du jour m'ont rassurÃ© sur ce point. Avec sa critique trop virulente des mÃ©thodes Agile, j'ai l'impression qu'il s'est mis toute l'assistance Ã  dos (350 personnes !).

Gail OlisÂ : Â«Â Le PÃ¨re-NoÃ«l et autres mÃ©thodologiesÂ Â»

La sÃ©ance suivante est prÃ©sentÃ©e par Gail Ollis : "Santa Clauss and other methodologies." Elle nous a rappelÃ© deux mÃ©thodologies qu'elle a utilisÃ©es il y a une quinzaine d'annÃ©es : RTSASD et GDPM. Ces mÃ©thodes qui Ã©taient des rÃ©actions comprÃ©hensibles dans un contexte waterfall, mais qui sont toutes deux (heureusement) passÃ©es dans les oubliettes de l'histoire de la programmation.

Quelques idÃ©es Ã  retenir.

- "L'intÃ©rÃªt d'une mÃ©thodologie est inversement proportionnelle Ã  sa gÃ©nÃ©ralitÃ©" (Jackson, 1995)

- L'histoire du canard en plastique (cela nous est tous arrivÃ©) : on butte sur un problÃ¨me pendant des heures sans arriver Ã  le rÃ©soudre, puis on se dÃ©cide Ã  aller en parler Ã  un collÃ¨gue pour qu'il nous aide. Et lÃ , avant mÃªme que ce dernier ne dise un seul mot, la solution nous apparaÃ®t, trÃ¨s clairement. On aurait pu en parler Ã  une plante verte ou Ã  ... un canard en plastique, le rÃ©sultat Ã©tait le mÃªme.

Elle compare enfin les diffÃ©rentes mÃ©thodologies existantes pour le dÃ©veloppement logiciel avec les diffÃ©rentes thÃ©rapies psychiatriques. C'est bien d'en connaÃ®tre le plus possible pour pouvoir prendre ce que l'on veut, ce qui va nous servir dans chacune d'elles, tout en sachant pourquoi, mais surtout de savoir pourquoi on ne veut pas de tout le reste.

Mike Hill, Giovanni AsproniÂ : Â«Â Outils, environnements et librairiesÂ : Å“uvre diabolique ou manne cÃ©leste ?Â Â»

J'ai dÃ©butÃ© l'aprÃ¨s-midi par un atelier : "Tools, Frameworks and Libraries: the Devil's work or Manna from Heaven?". Le but Ã©tait par petits groupes de lister les outils que nous utiliserions et ceux que nous n'utiliserions pas pour rÃ©aliser un des petits projets proposÃ©s.

Le groupe auquel j'ai participÃ© Ã©tait trÃ¨s homogÃ¨ne. Nous n'avons eu aucun mal Ã  lister nos outils : Linux (toutes distributions), gcc, subversion, log4cplus, gtk/wxWidets, sqllite, buildbot et make (autotools). C'est ce dernier qui serait le premier candidat pour Ãªtre remplacÃ© par un meilleur outil. Par contre nous n'avons choisi aucun des projets proposÃ©s, ces derniers Ã©tant trop distribuÃ©s pour Ãªtre faits en C++.

De cette liste finale, nous avons dÃ» retirer quelques candidats suite Ã  l'intervention du meneur, au milieu du jeu, pour nous annoncer que nos managers avaient un budget trÃ¨s serrÃ©. Ce fut le cas de Qt, mais aussi des compilateurs comeau ou Intel. Enfin nous est apparu ce qui nous manquait : un vrai bon dÃ©buggeur pour Linux. Ce serait notre petit projet Ã  faire en six semaines (MDR)

Quelques bonnes rÃ©flexions qui ont fait l'unanimitÃ© : pas de distribution Linux imposÃ©e (cela nous permet tout de suite en fonction des goÃ»ts de faire des tests sur plusieurs environnements) et par dessus tout pas d'Ã©diteur imposÃ© (il fallait Ã©viter une nouvelle guerre de religions emacs contre vim), en effet, pourquoi imposer un outil pour Ã©crire du texte ? Ce serait d'emblÃ©e se mettre Ã  dos deux dÃ©veloppeurs sur trois pour rien.

Les autres groupes on plus jouÃ© le jeu des projets et ont donc proposÃ© des solutions distribuÃ©es, C#, Python ou PHP sur serveur Apache avec des bases de donnÃ©es PostgreSQL ou Oracle. Un point pour C#, Python, PHP : la disponibilitÃ© de nombreuses librairies libres. Un seul des groupes vantait "l'achat de bonnes librairies de bon code." Ce Ã  quoi d'autres ont pu rÃ©pliquer qu'ils avaient dÃ©jÃ  Ã©ditÃ© des librairies en binaire afin de fixer certains bugs !

Pete GoodlifeÂ : Â«Â Histoire de deux systÃ¨mesÂ Â»

DerniÃ¨re prÃ©sentation de la journÃ©e par Pete Goodliffe: "A Tale of 2 systems." Rien de nouveau dans cette prÃ©sentation de deux projets auquel il a participÃ©, semblables dans leur environnement cible et dans leur domaine d'activitÃ©. Simplement l'occasion de rÃ©flÃ©chir Ã  notre mÃ©tier et une idÃ©e directrice : c'est le design du logiciel qui fait sa qualitÃ©.

Le premier projet montrait ce qu'il ne faut pas faire. Un projet qui a Ã©tÃ© dÃ©marrÃ© dans une Ã©quipe oÃ¹ chaque personne cherchait Ã  s'accaparer le code. Il a Ã©voluÃ© par ajouts successifs sans Ã  aucun moment faire de redesign salutaires qui auraient pu rembourser cette "dette technique" qui accumulait ses intÃ©rÃªts (j'aime beaucoup cette image).

L'analogie avec une ville peut surprendre mais permet de mettre en lumiÃ¨re le manque de structure, de voies de communications adaptÃ©es qui crÃ©ent des embouteillages. Un manque d'Ã©lÃ©gance et de cohÃ©sion qui demande des dons d'archÃ©ologie logicielle pour essayer de comprendre le fonctionnement et espÃ©rer pouvoir rÃ©soudre quelque bug ou ajouter quoi que ce soit.

L'autre projet a Ã©tÃ© dÃ©marrÃ© dans une Ã©quipe oÃ¹ chacun se sentait responsable de l'ensemble du projet. Le design haut niveau reste le seul document qui ne soit pas du code : il tient sur une page et consiste en deux diagrammes de quatre ou cinq blobs. Mais cette prÃ©sentation simple permet au dÃ©veloppeur d'apprÃ©hender trÃ¨s facilement et rapidement le projet. Il sait tout de suite oÃ¹ rajouter telle nouvelle fonctionnalitÃ©, dans une hiÃ©rarchie de fichiers claire. Chaque dÃ©veloppeur se sent responsable du design.

Pour terminer, le design n'a pas d'implications que sur le logiciel. Il influence aussi le moral et le turn over des programmeurs, la satisfaction des clients, du management, du dÃ©partement marketing.

Une rÃ©flexion pour finir : "Si vous apprenez quelque chose de vos erreurs, c'est bien. Si vous apprenez quelque chose des erreurs des autres, c'est mieux."

Jeudi 3 avril

Simon Peyton JonesÂ : Â«Â Contenir les consÃ©quences du monstre : le dÃ©fi de la prochaine dÃ©cÃ©nie.Â Â»

La keynote du jour est prÃ©sentÃ©e par Simon Peyton Jones : "Caging the Effects Monster: the next decade's big challenge." C'est le crÃ©ateur du langage Haskell : un langage de programmation fonctionnelle. Comme nous sommes habituÃ©s aux langages impÃ©ratifs, c'est une toute autre histoire qu'il nous propose. Plus de commandes pour dÃ©finir le flux de contrÃ´le, ici n'existent plus que des expressions qui dÃ©finissent le flux de donnÃ©es.

Haskell et les langages de programmation fonctionnelle reposent sur la puretÃ© (purity) des fonctions : elles n'ont pas d'effets secondaires. Les mÃªmes valeurs en entrÃ©e produiront toujours les mÃªmes valeurs en sortie. Ainsi tout le programme peut Ãªtre optimisÃ©, parallÃ©lisÃ© sur plusieurs processeurs.

Une analogie avec le C++ est possible : en C++, on ajoute const pour dire qu'une fonction est pure. En Haskell, toutes les fonctions sont pures par dÃ©faut. Il faut prÃ©ciser quelles fonctions ne le sont pas : celles qui rÃ©alisent des entrÃ©es et sortie par exemple. Ca me rappelle une rÃ©flexion que j'avais eue il y a bien longtemps : je pensais qu'il aurait mieux valu inventer le mot clÃ© nonconst en C++ ...

Enfin voila. Il y a quelque chose dans l'air avec Haskell et les autres langages de programmation fonctionnelle (OCaml, Erlang, PLINX ...). En ces pÃ©riodes de multiplication des coeurs sur nos machines, trouver une nouvelle maniÃ¨re de les utiliser est peut-Ãªtre le futur.

Kevlin HenneyÂ : Â«Â L'objet Ã©goÃ¯steÂ Â»

Ensuite, Kevlin Henney : "The Selfish Object". Une suite d'idÃ©es pour aider au design des objets. Les trois qualitÃ©s qu'un objet doit avoir : "ignorance, apathie et individualisme." Avec cette sÃ©rie de points de vue dÃ©calÃ©s comme celui-ci qui m'a bien fait marrer : "La terre est peuplÃ©e de choses en mÃ©tal avec des roues qui se dÃ©placent autour de cubes de bÃ©tons et qui ont des trucs roses comme serviteurs."

Difficile de sortir une suite trÃ¨s logique de la prÃ©sentation trÃ¨s riche. Quelques techniques d'inversion de contrÃ´le, qui permettent de compenser le fait que les diagrammes de classes vont gÃ©nÃ©ralement vers le haut alors que les diagrammes de packages vont vers le bas ! Le mot d'ordre gÃ©nÃ©ral : "RÃ©duire le couplage et amÃ©liorer la cohÃ©sion", pour Ã©viter "en attrapant la banane, de ramener le gorille avec."

"Parametrize from above." Les paramÃ¨tres sont lÃ  pour cela. Et pas question d'avoir un gros objet de contexte que l'on passe Ã  tout le monde. Non, on passe juste ce qu'il faut, c'est Ã  dire juste ce dont les fonctions ont besoin. Enfin sur le nommage, donner un nom aux classes d'interfaces en fonction de qui va les utiliser et non de qui va les implÃ©menter.

Kevlin Henney, Peter Sommerlad, Giovanni AsproniÂ v: Â«Â DÃ©crypter la simplicitÃ©Â Â»

Encore un petit atelier en dÃ©but d'aprÃ¨s midi : "The simplicity workout." Pas question ici d'aller vers le simplisme, non. C'est plutÃ´t un travail en cours sur ce qui fait qu'un programme est simple et Ã©lÃ©gant.

Quelques exemples de ce qui est simple :

- quicksort tout d'abord, explicable en deux phrases, implÃ©mentable en 5 lignes.

- MapReduce de Google, leur algorithme d'indexation.

- La notion de conteneurs et d'algorithmes de la librairie standard C++ aussi.

- UNIX pour ses entrÃ©es et sorties de fichiers qui s'appliquent Ã  tout, mÃªme Ã  l'Ã©cran.

- UNIX encore pour la composabilitÃ© avec les redirections, tuyaux et filtres.

- L'interface utilisateur de Google enfin.

Une technique potentielle pour faire du code simple : le dÃ©veloppement dÃ©crÃ©mental. Il consiste Ã  dÃ©terminer ce qui est nÃ©cessaire et Ã  Ã©liminer le reste. Pas facile. Suite Ã  l'atelier proprement dit, oÃ¹ nous avons dÃ» par petits groupes simplifier de petits programmes ou concepts, nous avons essayÃ© d'Ã©tablir une liste de ce que nous avions fait pour simplifier.

Les pistes : penser Ã  la totalitÃ© du systÃ¨me et ne pas chercher Ã  rÃ©soudre trop localement. Ceci nÃ©cessite bien Ã©videmment de comprendre ce que fait le programme, mais peut-Ãªtre aussi de comprendre ce que l'on veut, c'est Ã  dire quel est le problÃ¨me que le programme cherche Ã  rÃ©soudre. Il faut parfois aussi commencer par simplifier avant de pouvoir comprendre, et ne jamais perdre de vue le but lors du refactoring.

Andrei AlexandrescuÂ : Â«Â L'allocation mÃ©moire : l'aimer ou la dÃ©tester (ou penser que c'est trÃ¨s bien comme cela)Â Â»

DerniÃ¨re sÃ©ance par Andrei Alexandrescu : "Memory Allocation: Either Love it or Hate it (Or Think It's Just OK)." L'allocation mÃ©moire fait partie de ces problÃ¨mes insolubles, au sens de l'IncomplÃ©tude. Ã‰tant donnÃ© un allocateur, il est toujours possible de trouver un programme avec qui cet allocateur sera pire que tout. L'allocateur optimal universel n'existe pas. Le compromis se trouve entre un allocateur trÃ¨s gÃ©nÃ©ral et un allocateur trÃ¨s spÃ©cialisÃ©.

Windows XP utilise un allocateur de meilleur choix (qui, soit dit en passant, n'est pas meilleur que l'allocateur de pire choix). Linux utilise un allocateur de Doug Lea, la rÃ©fÃ©rence des allocateurs, un assez bon compromis. Cela ne sert Ã  rien de chercher Ã  faire un allocateur gÃ©nÃ©raliste : sur 8 projets utilisant un allocateur spÃ©cialisÃ©, 6 ont vu une amÃ©lioration de performance en remettant l'allocateur par dÃ©faut.

Les pistes pour amÃ©liorer la performance sont Ã  rechercher en spÃ©cialisant l'allocateur pour un programme donnÃ©. Il faut d'abord collecter des donnÃ©es, et dans le cas oÃ¹ certaines tailles d'allocations se rÃ©pÃ¨tent, il est possible d'utiliser des Free Lists spÃ©cialisÃ©es. Le reste des allocations pouvant se faire dans des Regions. Le modÃ¨le final est une combinaison des deux portant le nom de Reaps.

Pourquoi tant d'intÃ©rÃªt dans l'allocation mÃ©moire ? Tout simplement parce que c'est gÃ©nÃ©ralement lÃ  oÃ¹ un profileur vous indiquera que votre programme passe la plus grosse partie de son temps.

Vendredi 4 avril

Andrei AlexandrescuÂ : Â«Â Puissiez-vous vivre une Ã©poque intÃ©ressanteÂ Â»

La journÃ©e commence avec celui qui l'a terminÃ©e la veille, Andrei Alexandrescu : " May You Live Interesting Times". Il s'agit de C++, pur et dur. Andrei nous montre au travers de la fonction identity, puis des fonctions du test de Stepanov's Litmus : min, swap, et find que le type des variables n'est pas toujours transportÃ© en C++.

En C++98 tout d'abord. Pourtant, Ã©crire une fonction qui renvoie ce qu'on lui donne, "this is not rocket surgery!" :-) Il faut en faire deux, une const et une non const. Mais c'est loin de marcher dans tous les cas ... En C++0x, avec les r-value reference (&&) ce sera beaucoup mieux. Mais il y aura encore des cas oÃ¹ Ã§a ne passera pas.

Pour la fonction min, une nouvelle implÃ©mentation a Ã©tÃ© proposÃ©e pour le nouveau standard. Elle fait 175 lignes, dÃ©clare 10 types et 12 spÃ©cialisations (de templates). Elle a Ã©tÃ© refusÃ©e. Pour swap ce n'est pas mieux. Il est difficile de faire sans copier les valeurs. Cela devrait pourtant Ãªtre simple, en Haskell, swap tient une demi ligne ! Pour find, aucune amÃ©lioration attendue, sinon une syntaxe plus concise (auto) et de meilleurs contrÃ´les (et messages d'erreurs) avec les concepts.

Il y a des experts de classe internationale en prÃ©processeur (ils maÃ®trisent l'opÃ©rteur ##). Il y a des experts de classe internationale en name lookup (ils connaÃ®ssent ce que fait f(x)). Il y a de la place pour des experts de classe internationale en r-value references. De mÃªme en concepts.

Ces concepts qu'est ce que c'est ? Personne ne sait encore. Mais les Ã©volutions successives le montrent : les procÃ©dures, la pile d'appels, les fonctions qui travaillent avec des fonctions (templates) et les fermetures (closures) qui travaillent avec des donnÃ©es qui n'ont pas encore Ã©tÃ© dÃ©finies ont apportÃ© chacun un renouvellement. Le prochain s'appuiera sur les concepts.

Allan KellyÂ : Â«Â Les managers : Ã€ quoi sont-ils bons ?Â Â»

Ensuite, un petit atelier : "Managers: What are they good for?" par Allan Kelly. AprÃ¨s une petite prÃ©sentation s'appuyant sur quelques passages du Mythical Man Month (Brooks, 1975) l'assistance s'est sÃ©parÃ©e en deux, dÃ©veloppeurs d'un cÃ´tÃ©, managers de l'autre. Et chaque groupe a fait une liste de ce qu'il reprochait Ã  l'autre groupe ...

Les listes Ã©taient remplies de stÃ©rÃ©otypes. Mais une idÃ©e gÃ©nÃ©rale qui Ã©manait de tous les groupes de chaque camp, c'est le manque de confiance. Le principe de Peter a bien sur Ã©tÃ© rappelÃ© pour l'occasion.

Puis la prÃ©sentation a repris, sur l'inflation des titres. On colle un titre de manager Ã  n'importe qui de nos jours. Il existe des managers de tout et n'importe quoi. Mais pour les programmeurs, manager, c'est un mot qui pue. Quand une classe s'appelle quelque_chose_manager c'est mauvais signe. Cela signifie que c'est une classe fourre tout dont on ne sait pas bien quel est le rÃ´le.

Pour finir, les groupes de dÃ©veloppeurs ont fait une liste de ce qu'ils aimeraient que les managers fassent. De leur cÃ´tÃ©, les managers ont fait la liste de ce qu'ils aimeraient bien faire (eux-mÃªmes). Et ces listes Ã©taient assez similaires en fait. C'Ã©tait le but de la prÃ©sentation.

Tom GilbÂ : Â«Â Concevoir l'adaptation et la maintenance par l'ingÃ©nierie logicielle : une approche quantifiÃ©eÂ Â»

DÃ©but d'aprÃ¨s midi Ã  nouveau avec Tom Gilb : "Designing Maintainability and Adaptibility by Software Engineering: a Quantified Approach." Comment mesurer la capacitÃ© de maintenance (maintainability) ? En hardware, on utilise le MTTR (mean time to repair) ou temps moyen pour rÃ©parer. Et donc il nous a demandÃ© quels Ã©taient nos MTTR ? Et que ferions nous si nous devions fournir un MTTR de 1 seconde ?

Une partie de la sÃ©ance a Ã©tÃ© dÃ©diÃ©e Ã  recadrer qu'est ce qu'Ã©tait l'ingÃ©nierie, par rapport Ã  la technique. Il en est ressorti que c'est l'application des principes de la science afin de calculer des prÃ©dictions numÃ©riques et des mesures basÃ©es sur la connaissance et l'expÃ©rience. Waouh. Les mesures. VoilÃ  ce qui nous manque dans l'ingÃ©nierie logicielle.

Dans deux exemples, il nous a montrÃ© des listes d'exigences (requirements) peu recommandables. Pourtant je suis certain d'en avoir dÃ©jÃ  vu passer des comme Ã§a : "Rock solid robustness", "user friendly", "easy to maintain" ... Peut-Ãªtre mÃªme d'en avoir Ã©crit ! Bref il faut quantifier, donner une mesure. Et il a inventÃ© un langage pour Ã§a le "planguage".

Il nous a incitÃ© Ã  aller lire son papier "Inversion Programming" sur son site (gilb.com) et nous n'avons pas eu le temps de parcourir plus en avant sa prÃ©sentation. Les 90 minutes Ã©taient Ã©coulÃ©es, mais il nous a dit qu'il avait rÃ©ussi Ã  faire passer son message. Ah bon ?

Jim Hague, Russel WinderÂ : Â«Â DistribuÃ© ou non distribuÃ©, ou comment connaitre votre SCVD Ã  partir de votre SCVÂ Â»

Fin d'aprÃ¨s midi avec Jim Hague et Russel Winder : "To distribute or not to distribute or How to know your DVCS from your VCS."

Petite Ã©volution des systÃ¨mes de contrÃ´le de version (VCS), en partant des backups (!) puis de SCCS et enfin RCS, avant que CVS n'apporte l'utilisation concourante et la liaison distante, une Ã©tape majeure qui marquera CVS comme une rÃ©fÃ©rence dans le contrÃ´le de version. Enfin Subversion qui corrige les dÃ©fauts de CVS. Mais il est dÃ©jÃ  rattrapÃ©, et mÃªme dÃ©passÃ© par d'autres : git, bazaar, mercurial, darcs : des systÃ¨mes qui n'ont plus de dÃ©pÃ´t central. Ceux qu'on appelle des systÃ¨mes de contrÃ´le de version distribuÃ©s (DVCS).

Petit prÃ©sentation live de l'utilisation de bazaar (bzr) et mercurial (hg). Tous deux ont des syntaxes ligne de commande trÃ¨s proches de CVS (et SVN), Ã  l'opposÃ© de git qui possÃ¨de 178 commandes distinctes (!) et de nombreuses options pour chacune. Chacun crÃ©e un dÃ©pÃ´t (ou une branche selon sa terminologie) en local oÃ¹ l'on peut commiter ses changements. On peut ensuite les publier, les transfÃ©rer vers d'autres. Mais on garde toujours sa branche, son historique en local, tout en ayant la possibilitÃ© d'en importer d'autres.

Bazaar est supportÃ© par Canonical Ltd (ubuntu) et vient de passer comme projet GNU. En plus d'Ãªtre un systÃ¨me VCS complet qui gÃ¨re bien les branches et les fusions, il a une fonctionnalitÃ© trÃ¨s intÃ©ressante de pouvoir se lier Ã  un serveur Subversion. On peut ainsi avec un dÃ©pÃ´t bzr local, faire des commits locaux, puis pousser ces commits sur le serveur svn immÃ©diatement, ou plus tard.

Mercurial de son cÃ´tÃ© n'offre pas ce systÃ¨me de liaison. Mais il propose tout le reste, branches et fusions compris. Il a une maniÃ¨re un peu dÃ©routante de prÃ©senter les branches, mais les morceaux d'interface graphique que j'ai vus m'ont paru trÃ¨s pertinents. Et c'est peut-Ãªtre de ce cÃ´tÃ© qu'il y a quelque chose Ã  aller chercher.

Pour conclure, si Subversion vous va, que vous Ãªtes toujours connectÃ©s et que vous pouvez donc toujours accÃ©der au dÃ©pÃ´t central, il n'y a pas vraiment de raisons de changer. Mais si vous bougez un peu, que vous souhaitez un peu plus de libertÃ©, sans avoir Ã  passer toujours par le serveur et son cerbÃ¨re, essayez un DVCS, vous serez comblÃ©s.

Samedi 5 avril

Roger OrrÂ : Â«Â Les sept pÃªchÃ©s capitaux du debuggageÂ Â»

Dernier jour, Roger Orr : "Seven Deadly Sins of Debugging". There is no silver bullet. Il y aura toujours des bugs, et il faudra toujours dÃ©bugger. Par contre, il regrette qu'il y ait si peu de livres traitant du sujet : le debuggage. Il nous cite jute un livre rÃ©cent : "Advanced Windows Debugging". Enfin il fait une analogie entre le debuggage et le travail de Sherlock Holmes, qui consiste Ã  trouver ce qui s'est passÃ©.

Voici donc les 7 pÃªchÃ©s capitaux du dÃ©bugage.

- L'inattention, parce que nous sommes humains, contrairement Ã  un ordinateur qui ne se lasse jamais (get bored).

- La fiertÃ©, bien que vertu du programmeur Perl, nous fait Ã©crire parfois du code trop avancÃ©.

- La naÃ¯vetÃ© qui nous laisse Ã  penser que cela ne peut pas mal se passer.

- La colÃ¨re qui brouille notre capacitÃ© de jugement et nous fait refuser de voir la rÃ©alitÃ©.

- La paresse qui nous fait minimiser la portÃ©e d'un bug, pour Ã©viter le travail pourtant nÃ©cessaire.

- L'accusation (blame) quand chacun s'Ã©crie : "Ma partie fonctionne" ou reporte l'erreur sur l'OS ou le compilateur.

- Le flou, ou l'imprÃ©cision quand le rapport de bug indique juste que : "Ã§a plante".

Heureusement pour nous, l'antidote Ã  chacun de ces pÃªchÃ©s existe. Il faut fait preuve d'observation, d'humilitÃ©, de sagesse, de patience, de diligence, de responsabilitÃ© et de prÃ©cision. Debugger, ce n'est pas de la magie noire. C'est un art difficile, et on va devoir continuer avec, car cela n'a pas de raisons de s'amÃ©liorer.

James CoplienÂ : Â«Â Les rÃ©ponses Ã  cinq mythes AgileÂ Â»

Ensuite, James Coplien : "Five practical solutions to Agile Myths." Bien que dÃ©fenseur du manifeste Agile, il nous livre quelques Ã©cueils Ã  Ã©viter qui ont Ã©tÃ© amenÃ©s par les mÃ©thodes XP et SCRUM. "Agile n'a fait qu'essayer de ramener la programmation Ã  ce qu'elle Ã©tait il y a 40 ou 50 ans, avant que les managers n'arrive pour gÃ©rer le risque."

Le On-Site Customer fatigue l'Ã©quipe Ã  force de changements. Les User Stories qui se transforment en vagues requirements. Le Test Driven Development (TDD) fait pour une architecture procÃ©durale qui indroduit un couplage nÃ©faste entre le code et les tests. You Ain't Gonna Need It (YAGNI) aussi.

Les questions ont beaucoup portÃ© sur cette accusation au TDD, mais Cope prÃ©fÃ¨re les Design by Contract (les assertions). Les tests unitaires demandent Ã  peu prÃ¨s autant de code que le code lui-mÃªme. Pourquoi est-ce que ayant deux fois plus de code il n'y aurait pas deux fois plus de bugs ?

Il ne faut pas perdre de vue le but. Programmer pour que la barre de JUnit devienne verte n'en est pas un. TDD apporte peut-Ãªtre des effets positifs Ã  court terme, mais c'est un problÃ¨me Ã  long terme. Enfin, il a fini en nous disant qu'il ne pensait vraiment que la moitiÃ© des choses qu'il nous a dites ... Je n'arrive pas Ã  faire le tri.

Petit supplÃ©ment. James Ã©tait au bar de l'hÃ´tel le soir. La discussion Ã©tait trÃ¨s animÃ©e et portait toujours sur ce mÃªme sujet. Il a bien prÃ©cisÃ© que son argumentation Ã©tait fondÃ©e. Il a fait une thÃ¨se sur le sujet ("I made my homework. I got a PhD"). Ce que j'en ai compris, c'est que les tests du TDD (et lÃ  personne se semblait mettre la mÃªme dÃ©finition derriÃ¨re) portent sur les interfaces du programme, pas sur sa structure interne. Ou encore que le TDD se base sur des tests d'intÃ©gration plutÃ´t que des tests unitaires.

Didier VernaÂ : Â«Â Performance et gÃ©nÃ©ricitÃ© : le pouvoir oubliÃ© du LispÂ Â»

L'aprÃ¨s midi prÃ©sentation par Didier Verna, franÃ§ais, enseignant Ã  l'EPITA : "Performance and Genericity: the forgotten power of Lisp." Tout d'abord, arrÃªtons de railler les parenthÃ¨ses. Il nous a montrÃ© des morceaux choisi de C++ avec templates et de Lisp, c'est vrai qu'il n'y en a pas un des deux qui soit plus lisible que l'autre ...

AprÃ¨s un petit rappel de tout ce que peut faire Lisp : typage dynamique ou statique, langage fonctionnel et impÃ©ratif ... Il nous a montrÃ© le rÃ©sultat de ses recherches sur la performance. En comparant les temps d'exÃ©cution de routines de traitements d'images Ã  la fois en C et en Lisp, il arrive Ã  la conclusion que le Lisp est aussi rapide que le C. Il faut pour cela bien optimiser le Lisp en aidant le compilateur Ã  faire du typage statique, mais c'est pareil au final. Et donc l'idÃ©e serait qu'on peut faire du Lisp sans se soucier de performance. Il faut juste aider un peu le compilateur lÃ  oÃ¹ c'est nÃ©cessaire.

La deuxiÃ¨me partie consistait en l'utilisation avancÃ©e du CLOS, le Common Lisp Object System. Ici, il nous a dÃ©crit les multi-mÃ©thodes, qui sont plus avancÃ©es que les fonctions de classe C++ puisque pouvant Ãªtre virtuelles sur plusieurs objets Ã  la fois IYSWIM. Puis de lÃ , il a surchargÃ© le mÃ©canisme interne du SLOC afin de rajouter des contrÃ´les pour que toutes les fonctions nÃ©cessaires soit bien dÃ©finies par le programmeur, pour toutes les classes.

DiffÃ©rents invitÃ©sÂ : Â«Â Ã‰tat des lieux de la professionÂ Â»

VoilÃ , la journÃ©e et la confÃ©rence se sont terminÃ©es sur une discussion entre quelques orateurs : "State fo the Practice." Leurs rÃ©ponses en introduction : "On ne se focalise pas assez sur la valeur ajoutÃ©e." Tom Gilb ; "On a oubliÃ© qu'il s'agissait d'une activitÃ© humaine." Hubert Matthews ; "Il y a tant de gens qui ne font pas les choses correctement (euphÃ©misme)." Russel Winder ; "L'acadÃ©mie n'a pas rÃ©ussi Ã  Ã©lever le niveau." Peter Sommerlad ; "C'est comme si on voulait savoir si les gens baisent correctement ? Ce n'est pas une question, il n'y a rien Ã  rÃ©pondre." James Coplien.

Un sujet important a Ã©tÃ© la question de l'enregistrement de la profession d'ingÃ©nieur logiciel, comme on enregistre les mÃ©decins, ou les architectes. Pas grand monde ne soutient cette idÃ©e, mÃªme si on en parle, ici en Angleterre. Et puis quelle serait la consÃ©quence sur les dÃ©veloppements de logiciels libres ?

La question de la qualitÃ© des logiciels est revenue Ã  propos des consultants. Ils sont nombreux et finalement trouvent que si le logiciel qu'ils ont vendu fonctionne bien, ils ont tendance Ã  perdre le contrat de support. Et donc, c'est mieux de continuer Ã  faire de mauvais logiciels. Un peu moins mauvais que les concurrents, mais avec plein de bugs dedans.

Ainsi, HM avait demandÃ© Ã  Microsoft quand est-ce qu'ils arrÃªteraient de faire des logiciels si mauvais ? "Quand vous ne les achÃ¨terez plus !" Ou PS qui souhaite des compilateurs qui dÃ©tectent la compÃ©tence du programmeur. Pour le C++, c'est dÃ©jÃ  fait : qui comprend les messages d'erreurs des templates ?

Pour finir, l'idÃ©e gÃ©nÃ©rale est que le logiciel a envahi et dÃ©truit de nombreux secteurs industriels (un reboot de lave vaisselle) que nous sommes redevables envers des pans entiers de l'Ã©conomie. On a tellement bousillÃ© de choses qu'on ne peut que faire mieux. On va continuer Ã  travailler Ã  l'amÃ©lioration des logiciels parce que les programmeurs ont envie de bien faire. N'oublions pas que la seconde motivation est le fun. Et on a envie d'avoir du fun en programmant. Alors allons y !

Pour finir ...

Cet article compile une liste de liens vers des blogs qui commentent cette confÃ©rence. Ils contiennent des articles portant sur des sessions auxquelles je n'ai pas assistÃ©, et qui ne sont pas dÃ©crites dans cet article, ainsi que d'autres points de vue, ou anecdotes. Attention : tout est en anglais.

La confÃ©rence de l'ACCU 2009 aura lieu du 22 au 25 avril, toujours Ã  Oxford en Angleterre.