Intro

SCRUM, Extreme Programming (XP), Lean-management, le développement agile, c’est tendance !

Objectifs : améliorer la réactivité, la qualité et le coût du logiciel avec en ligne de mire la sacro-sainte satisfaction client.

J’ai participé, pendant deux ans, à un projet réalisé « from scratch » en suivant une méthodologie agile : l’Extreme programming. En tant que développeur (sur les deux ans), et « coach XP » (sur les six derniers mois).  L’objectif du projet était le développement d’une application de trading « in-house » dans une banque d’investissement, la taille de l’équipe a varié au cours de ces deux ans de 3 à 7 (manager compris).

Ce post a pour but d’expliquer les pour et les contre de cette méthode tel que je l’ai vécu.

L’extreme programming

Sans chercher à être exhaustif (wikpedia est ton ami), voici les grands principes XP :

• Pair-programming : on code à deux devant un PC, le codeur et le reviewer. les rôles s’inversant régulièrement. On change de binôme à chaque tâche.
• TDD (Test driven development) : chaque méthode, chaque portion de code est systématiquement testée avant d’être codée.
• KISS (Keep It Simple, Stupid) : On cherche toujours la solution la plus simple sans anticiper les besoins futures (pêché mignon du développeur ?).
• Refactoring : On cherche en permanence à avoir le code le plus propre possible
• Itérations courtes : le cycle développement-release est très court (1 semaine à 1 mois)

Les plus

• Un code clean : Non seulement l’XP via ses principes favorise une plus grande qualité de code, mais j’irai plus loin : il l’impose ! En effet, le TDD dans du code spaghettis, dupliqué, du code mort…c’est sinon impossible, franchement pénible. Idem pour le refactoring, très cher s’il n’est pas fait suffisamment tôt.
• Agilité : Je vous entends « Il est malin le type, c’est l’objectif ! ». Ok, mais c’est un objectif atteint. Le client peut changer d’avis et ses priorités comme de chemise (et il ne s’en prive pas).
• L’équipe te rend plus fort : Grace au pair-programming, les développeurs montent rapidement en compétence. Pour le développeur, c’est l’opportunité de se former grâce au reste de l’équipe. Se former sur l’application bien sur, mais aussi sur tout ce qu’on peut apprendre à observer un autre développeur à l’oeuvre.
• Interchangeabilité : XP refuse la spécialisation, chaque développeur doit maîtriser l’ensemble de l’application. C’est possible en associant sur chaque développement un « sachant » et un « ignorant » sur la partie concernée. C’est clairement un luxe pour le manager étant donné le turnover dans la plupart des projets informatiques. Les mauvaises langues parleront de développeur « jetable », mais pour le projet, c’est un plus.

Les moins

• Dites au revoir à votre « Touch » : Si vous aimez utiliser vos raccourcis « custom », vos conventions de nommage, vos patterns, vos lib. Bref ! VOTRE façon de coder : Oubliez ! vous allez coder la moitié du temps sur un autre PC, et quelqu’un d’autre codera sur le votre. L’uniformisation des l’environnement, des outils et des pratiques est par conséquent obligatoire. C’est positif pour le projet, mais l’effort d’adaptation est réel.
• Explications, négociations, compromis : Développer à deux, ce n’est pas naturel. Il faut en permanence argumenter, expliquer son cheminement de pensée. Quand au reviewer, il doit rester concentrer sans le clavier, challenger chaque décision,  être force de proposition et chasser chaque bug ou coquille, il doit enfin être patient s’il maitrise mieux le sujet sans chercher à « attraper » le clavier. Il faut aussi veiller à garder un équilibre, le plus timide ou le plus junior ne devant pas se faire « manger ». Bref, c’est formateur, le code écrit est meilleur, mais je suis convaincu que c’est plus exigent que de coder seul.
• Le TDD, ce n’est pas sexy : Je suis fermement convaincu de l’intérêt du TDD (limitation des bugs et des régressions, refactoring sure, spécification, code découplé), mais il faut avouer qu’écrire des centaines de tests et avoir la (fausse ?) impression d’aller deux fois moins vite, c’est parfois rébarbatif.
• Pas de petit chef : Le pair-programming, l’absence de spécialisation et la volonté en XP d’aller vers l’essentiel (le code) limite quelque part les responsabilités du développeur. Dans une équipe classique, chaque développeur deviendra probablement référent sur certains domaines, participera à des réunions, et prendra en charge certaines responsabilités.  En XP, le manager manage, les codeurs codent (PS : si c’est tout ce que vous aimez, vous pouvez passer cela dans la rubrique plus), et nul n’est indispensable.

Avant de conclure, quelques remarques inclassables, ni en plus, ni en moins

L’extreme programming, à prendre ou a laisser.

Je ne vois pas les différentes pratiques de l’XP comme une boîte à outil où l’on prend et on jette en fonction des envies. Les différentes pratiques se complètent et se renforcent mutuellement.

• Pour livrer très fréquemment, il faut pouvoir valider une version très rapidement, d’où le TDD. (Si vous voulez tester l’application de fond en comble tous les 15 jours à la main, ce sera sans moi).
• Prendre systématiquement la solution la plus simple en négligeant le refactoring, c’est la porte ouverte au code spaggeti et autres rustines.
• Faire du refactoring fréquemment sans couverture de tests unitaires, c’est l’assurance de régressions.
• Refactorer, c’est bien plus sûr avec une deuxième paire d’yeux.

Bien sur, ça n’est pas vrai pour tout,  le TDD n’a pas attendu l’XP pour exister.

N’est pas XP qui veut

Tout projet n’est pas adapté à l’XP. Il faut un client accessible et prêt à s’investir et des développeurs ouverts aux pratiques XP. Il faut enfin que le manager soit convaincu par la méthode et à l’écoute des développeurs (accepter les coûts donnés par des développeurs et les dépassements inévitables par exemple).

L’environnement de développement est également primordial. Framework de tests unitaires, de mocking, outils de refactoring, d’analyse statique de code, de couverture de tests, usine de build…Tous ces outils « nice-to-have » dans un autre projet deviennent plus ou moins indispensables en XP. En conséquence,  un projet C++ ou dans un langage web est sans doute moins adapté à l’XP qu’un projet Java ou .NET.

Conclusion

Au final, même si j’ai la critique un petit peu facile par nature, je me range plutôt du côté des « pro-XP / pro-agiles » .Le projet auquel j’ai participé est à mon avis un succès, mais il est important de noter qu’il correspond en tous points au « contexte idéal » décrit ci-dessus.

Quant aux objectifs mentionnés au début du post (améliorer la réactivité, la qualité et le coût du logiciel), les deux premiers sont clairement atteints. Pour le troisième,  c’est la question à 1 Milliard.

Ce qui est sûr, c’est que l’on est très loin d’un coût multiplié par quatre. Certes on code deux fois plus (TDD), et à un instant donné, la moitié de l’équipe ne code pas (elle ne dort pas non plus). Mais cela est compensé par des bugs à fixer en moins, un code de meilleur qualité, une montée en compétence plus rapide et un scope correspondant exactement au besoin client. Est-ce que c’est « surcompensé » ou « sous-compensé », là est le vrai débat. Mon intuition c’est que le gain est négatif dans un premier temps (un an, peut-être deux) puis positif par la suite.

Voilà pour ma vision de l’Extreme programming, à prendre pour ce que c’est, un avis basé sur une expérience mais certainement pas une vérité.

The post Extreme programming : retour d’expérience first appeared on In Fine - Le Blog.

Détecter les deadlocks en C# / .NET grâce au pattern IDisposable

Si vous êtes développeur en environnement multithread, alors vous vous êtes déjà posé cette question : Où est ce deadlock ? !

Bien sûr, ce deadlock est non-reproductible, il survient chez l’utilisateur, et l’on peut passer des heures à le chercher. Sans jamais être sur d’avoir trouvé LE deadlock qui pose problème !

Vous trouverez dans ce post un exemple de lock qui a pour objectif de

1. Pouvoir détecter les deadlocks
2. Proposer une syntaxe claire et concise
3. Ajouter un overhead minimum en terme de performance à la syntaxe lock C# classique

Petit rappel : qu’est-ce  qu’un deadlock ?

Un deadlock (interblocage dans sa version française que personne n’utilise) est la situation dans laquelle 2 threads s’attendent mutuellement. Cas concret :

1. Un thread T1 acquiert une ressource R1
2. Un thread T2 acquiert une ressource R2
3. T1 demande la ressource R2
4. T2 demande la ressource R1

Avec un schéma :

Exemple de code provoquant un deadlock

void CreateDeadLock()
{
   Object R1 = new object();
   Object R2 = new object();

   Thread T1 = new Thread(delegate() { Work(R1, R2); });
   Thread T2 = new Thread(delegate() { Work(R2, R1); });

   T1.Start();
   T2.Start();
}

void Work(Object acquire, Object demand)
{
   lock (acquire)//T1 take R1 and T2 take R2
   {
      Thread.Sleep(1000);//To ensure that the ressources are taken
      lock (demand)
      {
      }
    }
}

NB : Bien sûr, les situations réelles sont souvent plus compliquées, impliquant par exemple plus de 2 threads ou des locks implicites (écriture dans un fichier…).

Le lock C#

Quand en C# on écrit la syntaxe suivante :

lock (ressource)
{
}

Il se passe en fait à peu près ça :

Object temp = ressource;
Monitor.Enter(temp);
try
{
}
finally
{
   Monitor.Exit(temp);
}

Monitor.Enter acquière le lock, Monitor.Exit le relâche, Le block try-finally est là pour s’assurer que la ressource sera libérée même en cas d’exception. Quant à la référence “temp”, il garantit que c’est bien l’objet acquis qui sera libéré (l’utilisateur ne peut pas la modifier l’objet vers lequel “temp” pointe).

Prévenir les deadlocks avec un Timeout

Le principe pour prévenir les deadlocks implique l’introduction d’un timeout avec un log ou une levée d’exception dans le cas ou le thread échoue à acquérir la ressource demandée.

Voici un exemple de code résolvant le problème.

if (Monitor.TryEnter(ressource, 10000))
{
   try
   {
      //Work
   }
   finally
   {
      Monitor.Exit();
   }
}
else
{
   // Log, stack trace display...
   throw new TimeoutException("Lock acquiring failed");
}

Dans une application avec de nombreux locks, vous conviendrez que cette syntaxe est plus lourde et moins lisible que le lock classique.

Plus grave, elle laisse la possibilité « d’oublier » la libération de la ressource puisque celle-ci incombe au programmeur à chaque utilisation (sisi, ça peut arriver !).

Une solution plus « User-friendly »

L’objectif est de garder le bénéfice du timeout, tout en bénéficiant d’une syntaxe plus concise et claire.

L’idée ici est d’utiliser un Pattern bien connu des programmeurs C++, mais moins des développeurs C# ou JAVA, le principe RAII (Ressource Acquisition Is Initialization).

Le principe RAII

En C++, il y a un moyen simple de s’assurer qu’une ressource sera toujours libérée à la sortie d’une méthode, c’est de l’encapsuler dans un objet créé sur la pile, et de la libérer dans le destructeur de cet objet. En effet, lorsque la méthode se termine (que ce soit par return ou exception), le destructeur de l’objet est appelé et la ressource toujours libérée.

En C# cependant, on ne peut pas appliquer directement cet idiome. En effet :

-L’appel du destructeur d’une classe n’est pas déterministe (il est réalisé par le Garbage Collector)

-Les structures, équivalent C# des objets créé sur la pile en C++, ne peuvent pas avoir de destructeur.

Implémentation du lock par l’utilisation du pattern IDisposable

Pour contourner cette limitation du langage, on peut utiliser le pattern IDisposable.

Voici une première implémentation :

public class LockCookie : IDisposable
{
private const int TIMEOUT = 10000;
private Object _ressource;

public LockCookie(Object ressource)
{
   if (Monitor.TryEnter(ressource, TIMEOUT))
   {
      _ressource = ressource;
   }
   else
   {
      // Log, stack trace display...
      throw new TimeoutException("Lock acquiring failed");
   }
}

public void Dispose()
{
   if (_ressource != null)
   {
      Monitor.Exit(_ressource);
   }
}

}

Et son utilisation :

using (new LockCookie(ressource))
{
   //Work
}

Avec ce pattern, une seule ligne permet d’acquérir la ressource, la libération est systématique à l’accolade fermante (même en cas d’exception) et le traitement en cas d’échec n’est pas dupliqué.

CQFD ? Pas tout à fait. Même si l’on peut se satisfera de cette solution dans la plupart des cas, elle créé un overhead non négligeable : il y a création d’objet à chaque acquisition de la ressource (et qui dit création d’objet dit également plus de travail pour le Garbage Collector !).

Optimisation de la solution

Eliminons tout de suite une première piste : transformer notre classe LockCookie en type struct n’optimise pas la solution. Pourquoi ? Parce qu’à l’accolade fermante du using, la méthode Dispose de l’interface IDisposable est appelée, et appeler une méthode d’interface à partir d’un type struct implique un boxing.

Une autre piste consiste à faire de notre classe LockCookie l’objet même de synchronisation. Voici le code qui en résulte.

public class LockCookie : IDisposable
{
private const int TIMEOUT = 10000;
private bool _ressourceAcquired;

public LockCookie Get()
{
   _ressourceAcquired = Monitor.TryEnter(this, TIMEOUT);
   if (!_ressourceAcquired)
   {
      throw new TimeoutException("Lock acquiring failed");
   }
   return this;
}

public void Dispose()
{
   if (_ressourceAcquired)
   {
      //NB : the 2 next lines must be in is order to prevent _ressourceAcquired
      //to be set to true by Get() then reset by this call to dispose
      _ressourceAcquired = false;
      Monitor.Exit(this);
   }
}

}

Et son utilisation :

//For instance, ressource is a class field : LockCookie _ressource = new LockCookie();
using (_ressource.Get())
{
   //Work
}

L’utilisation est sans doute un peu moins évidente, mais aucun objet n’est créé et la libération de la ressource reste implicite et systématique.

Sur le plan des performances, un lock classique coûte selon mes tests 40 ns (40 milliardièmes de secondes), avec la première solution (avec création d’objet), le coût monte à 50 ns, soit un overhead de 25%, la seconde solution descent à 44 ns, soit un overhead de 10%. Le code des tests de performances sont disponibles en bas de l’article.

Conclusion

Ces 2 solutions apportent une réponse centralisée et efficace aux problèmes liés aux acquisitions de ressources en général et aux deadlocks en particulier. Le coût en terme de performance peut paraître important à certains, mais gardons à l’esprit que le temps d’acquisition d’un lock est souvent négligeable en comparaison du temps ou un thread est effectivement bloqué en l’attente d’une ressource. Je suis par ailleurs curieux de connaître d’éventuelles améliorations ou corrections que vous pourriez apporter.

Code d’analyse de la performance :

void TestPerf()
{
TestPerf(ClassicLock,”ClassicLock”);
TestPerf(LockCookieCreation,”LockCookieCreation”);
TestPerf(LockCookieGet,”LockCookieGet”);
}

public static void ClassicLock(){ lock (_lockObject) { } }
public static void UseLockCookie(){using (new LockCookie(ressource)){ } }
public static void UseLockCookie() { using (ressource.Get()) { } }

public delegate void TestPerfDelegate();
public static void TestPerf(TestPerfDelegate testPerfDelegate, string testName)
{
const long nbIteration = 10000000;//10 millions times
const long nanoSecCoeff = 1000000;//1 ms contains 1 million ns

Stopwatch stopwatch = new Stopwatch();
GC.Collect();//Prevent from garbage collection during loop
stopwatch.Start();
for (int i = 0; i < nbIteration; i++) { testPerfDelegate(); } stopwatch.Stop(); double ellapsedNanoSec = (double)(stopwatch.ElapsedMilliseconds * nanoSecCoeff) / nbIteration; Console.WriteLine(testName.PadRight(50) + ellapsedNanoSec); } } [/sourcecode]

The post Détecter les deadlocks en C# / .NET grâce au pattern IDisposable first appeared on In Fine - Le Blog.

Peut-être avez vous déjà utilisé les “options SNCF” pour les billets de train, qui vous permettent de “réserver” un billet pendant un certain temps sans l’acheter directement. Et bien son fonctionnement est quasiment identique à une option au sens financier du terme !

Voici ses caractéristiques :

• Le sous-jacent : C’est le billet de train, c’est le produit que vous récupérerez si vous exercez l’option.
• Le type : L’option vous donne droit d’acheter le billet, c’est donc une option d’achat (Call en anglais)
• Le style : Vous pouvez récupérer le billet n’importe quand jusqu’à une certaine date, il n’y a pas de date précise, c’est donc une option américaine
• La quotité : C’est le nombre de billets que vous aurez en exerçant l’option (nombre de sous-jacents par option)
• La maturité : C’est la durée de validité de l’option, si vous avez 1 mois pour acheter vos billets, la maturité de l’option est 1 mois.
• Le strike : C’est le prix du billet de train si vous décidez d’exercer l’option.

On retrouve donc dans l’option SNCF les caractéristiques d’une option en finance.

Il y a cependant une différence de taille, l’option SNCF est gratuite, mais comme rien n’est gratuit en finance, la problématique réside dans la détermination du “juste prix” d’une option donnée.

Pour les options SNCF, vous pouvez vous dire, c’est gratuit, je ne m’engage à rien, l’option me garantit un prix, et vous posez cette option.

Maintenant, imaginons que la SNCF décide de faire payer ces options. Si celle-ci coûte 1€, alors vous en déduisez que l’option est toujours intéressante…mais si l’option coûte 2 € ? 5 € ?

Quel est le prix à partir duquel vous déciderez de ne plus acheter cette option ?

Si vous arrivez à déterminer ce prix, alors vous avez “pricé” l’option !

Voyons en détail les critères qui permettent de déterminer le “bon prix”.

La moneyness

Ce terme barbare désigne une notion plutôt simple, celle qui a le plus d’impact sur le prix de l’option.

• Si le strike de l’option (le prix du billet garanti par l’option) est inférieur au prix actuel du billet, l’option est dite “in-the-money”. Par exemple, si le billet coûte 30€, et que l’option vous permet d’acheter ce billet à 20 €, alors l’option vaudra au minimum 10 €. Ces 10 € (prix du sous jacent – strike) sont également appelés “valeur intrinsèque” de l’option.
• Si le prix du billet est identique dans les 2 cas ( strike = prix du sous-jacent ), alors l’option est “at-the-money”, la valeur intrinsèque de l’option est nulle.
• Si enfin le prix du billet est plus grand dans le cas de l’option qu’en achetant directement le billet, alors l’option est dite “out-the-money”. Autrement dit, il faudrait-être fou pour exercer l’option immédiatement, la valeur intrinsèque de l’option est négative.

Le 1er critère du prix d’une option est donc le rapport entre prix du sous-jacent et strike de l’option.

La maturité

Prenons l’exemple d’un voyage prévu dans 3 mois. L’idéal pour vous est d’attendre au maximum avant d’acheter le billet. Si l’option vous oblige à acheter vos billet d’ici une semaine, l ‘option n’est pas vraiment utile, mais si elle vous permet d’acheter le billet dans 2 mois et demi, l’option devient beaucoup plus intéressante. En conséquence, le prix d’une option augmente avec sa maturité.

NB: ceci est vrai pour une option américaine, comme l’option SNCF, c’est également très souvent le cas pour une option européenne, mais pas systématiquement.

La volatilité

Voici 2 exemples pour comprendre ce qu’est la volatilité et son influence sur le prix d’une option. Prenons le cas du trajet entre “petit-village” et “la gare au milieu de la campagne”.

Hypothèse 1 : le train n’est jamais plein, vous trouverez toujours une place.

Hypothèse 2 : le prix du billet est toujours de 20€.

Si une option sur ce trajet possède un strike de 20, cette option ne sera pas intéressante puisque vous pourrez à tout moment acheter votre billet au même prix. Personne ne voudra payer pour une option qui ne sert à rien, son prix sera 0. Nous somme ici dans le cas où la volatilité du sous-jacent est nulle, son prix ne bouge jamais.

Prenons maintenant le cas du trajet “Paris-Nice le 15 août ”.

Hypothèse 1 : le train n’est jamais plein non plus (hypothèse hasardeuse, mais admettons).

Hypothèse 2 : Le prix du billet augment lorsque le train est presque plein (beaucoup plus crédible).

Vous voulez vous baigner ce week-end, mais seulement s’il fait beau !

Le billet coûte aujourd’hui 50€, mais personne ne sait comment le prix du billet évoluera tout au long de la semaine. S’il les prévisions météo deviennent mauvaises, le prix tombera peut-être à 30€, si elles sont bonnes, le prix pourrait bien être de 100€ Jeudi !

Nous sommes ici dans le cas ou le prix du sous-jacent est très volatile. Dans ce cas, une option qui vous garanti un prix fixe (60 € par exemple) est beaucoup-plus intéressante, car elle peut dans certain cas vous faire économiser 40 €, et s’il ne fait pas beau, alors vous n’exercez pas l’option. On peut comprendre ainsi que le prix de l’option augmente lorsque la volatilité du sous-jacent augmente.

Conclusion

On a pu voir ici 3 paramètres importants pour déterminer le prix d’une option, il en existe d’autres pour lesquels le parallèle est moins évident avec l’option SNCF (les taux d’intérêt par exemple), nous les verrons dans un prochain post. Nous verrons également  comment ces paramètres interviennent quantitativement pour fixer le prix d’une option.

The post Exemple d’option dans la vie quotidienne : l’option SNCF first appeared on In Fine - Le Blog.