Un billet sur le blog d'Excilys concernant les switchs en java me donne envie de parler un peu de codage en C#.

Tout développeur avec un peu d'expérience sait que les "switch" sont une grande source d'erreurs et une plaie pour la maintenabilité d'un code.
Un switch classique, ça donne quelque chose comme ça :

static class Switch
{
  public static string GetFunctionDescription (string functionName)
  {
    switch (functionName) {
    case "add":
      return "Compute the sum of two numbers";
    case "sub":
      return "Compute the difference of two numbers";
    default:
      throw new ArgumentException ("Unknown function");
    }
  }

  public static int Compute (string functionName, int op1, int op2)
  {
    switch (functionName) {
    case "add":
      return op1 + op2;
    case "sub":
      return op1 - op2;
    default:
      throw new ArgumentException ("Unknown function");
    }
  }
}

Et ça s'utilise comme ça :

Console.WriteLine( Switch.GetFunctionDescription("add") );
Console.WriteLine( "Result={0}", Switch.Compute("add",3,2) );

Dès que l'on veut rajouter un cas, on est presque sûr d'oublier quelque chose.
Alors, le polymorphisme de toute bonne conception orientée objet vient à notre secours et on peut remplacer nos cases par une interface et ses implémentations :

interface Function
{
  string Description { get; }
  int Compute (int op1, int op2);
}

class FunctionAdd : Function
{
  public string Description { get { return "Compute the sum of two numbers"; } }

  public int Compute (int op1, int op2) { return op1 + op2; }
}

class FunctionSub : Function
{
  public string Description { get { return "Compute the difference of two numbers"; } }

  public int Compute (int op1, int op2) { return op1 - op2; }
}

Du coup, on peut se contenter d'un switch unique qui sera bien plus facile à maintenir

static class Switch
{
  public static Function GetFunction (string functionName)
  {
    switch (functionName) {
    case "add":
      return new FunctionAdd();
    case "sub":
      return new FunctionSub();
    default:
      throw new ArgumentException ("Unknown function");
    }
  }
}

Console.WriteLine( Switch.GetFunction("add").Description );
Console.WriteLine( "Result={0}", Switch.GetFunction("add").Compute(3,2) );

Si on est vraiment allergique au mot-clef "switch", on peut aussi utiliser un dictionnaire pour référencer les cas en fonction de leur nom mais ça ne change pas grand chose en termes de maintenabilité. On a autant de classes dérivées que de "case" et on a un point central qui fait l'association entre les valeurs possibles et leur exécuteur.

static class Switch
{
  static Dictionary<string, Function> Functions { get; set; }

  static Switch ()
  {
    Functions = new Dictionary<string, Function> ();
    Functions["add"] = new FunctionAdd ();
    Functions["sub"] = new FunctionSub ();
  }

  public static Function GetFunction (string functionName)
  {
    if (!Functions.ContainsKey (functionName))
      throw new ArgumentException ("Unknown function");
    return Functions[functionName];
  }
}

Mais ce qui serait vraiment intéressant, ce serait d'évacuer complètement la maintenance d'un point central. Pour cela il faudrait pouvoir déclarer la valeur du "case" (dans notre exemple, le nom de la fonction) avec son exécution (dans notre exemple la classe qui implémente la fonction).

.NET offre un concept facile à mettre en oeuvre pour réaliser cela : les attributs.

Ainsi, on déclare un attribut pour nommer nos cas :

class CaseAttribute : Attribute
{
  public string Name { get; private set; }
  public CaseAttribute (string name) { Name = name; }
}

Et on l'utilise pour qualifier chacune de nos implémentations :

[Case("add")]
class FunctionAdd : Function
{
  public string Description { get { return "Compute the sum of two numbers"; } }

  public int Compute (int op1, int op2) { return op1 + op2; }
}

[Case("sub")]
class FunctionSub : Function
{
  public string Description { get { return "Compute the difference of two numbers"; } }

  public int Compute (int op1, int op2) { return op1 - op2; }
}

A partir de là, on peut implémenter un mécanisme générique pour réaliser les switchs, par exemple :

static class Switch<T> where T : class
{
  public static T On (string val)
  {
    var switchSelection = from type in Assembly.GetCallingAssembly ().GetTypes ()
      from attribute in type.GetCustomAttributes (false) as Attribute[]
      let caseAttribute = attribute as CaseAttribute
      where caseAttribute != null && caseAttribute.Name == val
      select type;
    
    if (switchSelection.Count () == 0)
      throw new ArgumentException ("Unknown case");
    
    if (switchSelection.Count () > 1)
      throw new ArgumentException ("Multiple implementations for same case !!!");
    
    return Activator.CreateInstance (switchSelection.First ()) as T;
  }
}

Et l'appel d'un switch reste relativement lisible :

Console.WriteLine( Switch<Function>.On("add").Description );
Console.WriteLine( "Result={0}", Switch<Function>.On("add").Compute(3,2) );

Avec l'implémentation ci-dessus, on est limité à utiliser les cas dans l'assembly où ils sont déclarés mais on pourrait bien sûr imaginer des choses plus évoluées...

Après le manifeste, voici les principes qui vont avec.

Le texte original en anglais est là : http://groups.google.com/group/software_craftsmanship/web/principles-of-software-craftsmanship.
Il est à l'état de brouillon mais n'en est pas moins intéressant.

L'éthique de l'artisan du logiciel

Nous veillons

Nous considérons qu'il est de notre responsabilité
d'acquérir la confiance des entreprises que nous servons
par conséquent,
nous donnons aux problèmes de nos clients l'importance qu'eux-mêmes y accordent et
nous engageons notre réputation sur la qualité du travail que nous produisons

Nous appliquons

Nous considérons qu'il est de notre responsabilité
d'écrire du code sans défaut, vérifié, lisible, compréhensible et malléable
par conséquent,
nous suivons minutieusement, même sous la pression, les pratiques que nous avons choisi et
nous travaillons nos techniques de manière régulière

Nous apprenons

Nous considérons qu'il est de notre responsabilité
d'améliorer notre savoir faire dans la recherche de la plus grande maitrise
par conséquent,
nous explorons en permanence de nouvelles technologies et
nous lisons et étudions les travaux des autres artisans

Nous partageons

Nous considérons qu'il est de notre responsabilité
de perpétuer l'art du Logiciel
par conséquent,
nous poussons les apprentis à l'acquérir et
nous engageons activement, avec les autres artisans, dialogue et pratique

Et quelques liens (en anglais) suite aux questions évoquées après la présentation :

• le groupe de discussion
• l'éthique et les principes des artisans du logiciel (en anglais). Voir aussi la liste initiale de citations qui a servi de base.

Cela faisait quelque mois que j'avais envie de parler d'artisanat du logiciel ou software craftsmanship en version originale. Ce sera chose faite vendredi prochain, le 18 juin lors du 14ème séminaire SigmaT.
Comme d'habitude, l'entrée est gratuite. Il suffit de s'inscrire en ligne.

Outre l'artisanat du logiciel, il y aura aussi Guillaume Saint Etienne qui parlera de TDD et de BDD, un retour d'expérience Scrum chez Sanofi-Aventis et une nouveauté SigmaT : un débat participatif sur les méthodes agiles.

Voici les points que j'essaierai d'aborder lors de ma présentation "Au delà de l'agilité, l'artisanat du logiciel" :

Quelqu'un qui prétend s'y connaitre un peu en méthodes agiles sans logo "Certified ScrumMaster" sur son blog, ça ne fait pas vraiment sérieux. Mais comme cette "certification" ScrumMaster ce n'est pas vraiment très sérieux non plus, il fallait trouver autre chose.

Emmanuel Chenu a la solution : sa proposition de logo autoproclamé "Experienced Extreme Programmer" est tout à fait ce qu'il me fallait.

Il m'est arrivé de dire du mal des certifications pour tout ce qui concerne le développement logiciel. Je reconnais que mes reproches sur le manque de sérieux d'un diplôme obtenu en 2 jours intenses n'étaient pas toujours justifiés.

Après avoir longtemps hésité, j'ai fini par franchir le pas et me voilà désormais "Certified Agile Software Specialist". Si, comme moi, vous voulez bénéficier d'une certification reconnue internationalement et recommandée par les plus éminents membres de la communauté agile, n'hésitez pas : http://www.agilecertificationnow.com/.

Lu sur le Journal Officiel

No d'annonce : 279
Paru le : 28/02/2009

Association : SOCIETE DES INNOVATEURS POUR LA GENERALISATION DES METHODES AGILES DE TOULOUSE (S.I.G.M.A.T.).

Identification WALDEC : W313011297

No de parution : 20090009
Département (Région) : Haute-Garonne (Midi Pyrénées)

Lieu parution : Déclaration à la préfecture de la Haute-Garonne.
Type d'annonce : ASSOCIATION/CREATION

Déclaration à la préfecture de la Haute-Garonne. SOCIETE DES INNOVATEURS POUR LA GENERALISATION DES METHODES AGILES DE TOULOUSE (S.I.G.M.A.T.).
Objet : fédérer et faire connaître les acteur de l’agilité de Toulouse et sa région, informer et initier aux méthodes agiles les personnes désireures de les découvrir, favoriser l’adoption des méthodes agiles dans le tissu économique régional.
Siège social : Hoegaarden Café - La Chunga, 52, route de Narbone, 31400 Toulouse.
Courriel : contact (at) sigmat.fr.
Site Internet : http://www.sigmat.fr.
Date de la déclaration : 9 février 2009.

Ca y est. L'association SIGMAT existe désormais officiellement !
Les inscriptions sont déjà ouvertes. On peut même s'inscrire en ligne.

Et bien sûr les séminaires trimestriels continuent. Le prochain, c'est demain, vendredi 27 mars, et il reste encore quelques places.

Denis Dollfus, avec qui j'ai eu le plaisir de travailler il y a quelques années chez Reuters, lance une enquête sur l'état d'agilité des projets de développement logiciel en France.

J'encourage tous ceux qui font du développement logiciel à y répondre, même s'ils n'ont jamais entendu parler "d'agilité".
En fait, l'info qui serait intéressante c'est la comparaison entre les résultats obtenus au test et le résultat attendus par les intéressés.

En ce qui me concerne, pas de surprise. Je savais que les questions 18 et 24 m'empêcheraient d'atteindre le 100%

Ceux qui ont réussi à atteindre le point (0,0), je les soupçonne d'avoir joué à chercher la réponse "qu'il ne faut pas donner". Quant à ceux qui dépasssent les 80% en ingénierie mais restent à zéro en management, je serais très curieux de voir comment ils fonctionnent...

Le prochain SigmaT aura lieu le vendredi 12 décembre à 16h00. J'y présenterai un retour d'expérience sur l'utilisation de Scrum chez Varian Medical Systems (dont j'avais évoqué les prémisses il y a fort longtemps).

Je pense avoir quelques trucs intéressants à raconter mais je préfère prévenir que cela risque de ne pas être aussi passionnant que le retour d'expérience XP chez Igeoss. Je viens d'ailleurs de mettre en ligne la prestation de David Desmarest que j'avais filmée lors de l'Agile Tour.

Les autres interventions filmées le 16 octobre ne sont malheureusement pas encore disponibles pour des raisons techniques (mon camescope m'a laché avant que je puisse les récupérer).

Ce n'est pas moi qui le dit, c'est James Shore dans son dernier billet. "Rescuing Scrum teams keeps me in business" avance même un de ses collègues.

La raison ? L'engouement pour Scrum a fait que nombre d'équipes insuffisamment préparées se retrouvent dans des situation inextricables de dette technique. Ils ont naïvement cru que l'on pouvait tirer bénéfice d'une gestion de projet agile sans en payer le prix.