L’extreme programming, comment ça se passe ?

On parle souvent ces temps-ci de l’eXtreme Programming (on écrira XP dans la suite), encore un terme à la mode inventé par les marketeux. Il s’agit en gros de bosser à deux sur un écran, comme si les ordis coûtaient trop cher. :-p. Bon plus sérieusement il y a de très bonnes raisons à ça et on va voir comment ça se passe en réalité.

Débloque les + belles offres tech en 10 mins

Les fondements de l’eXtreme Programming

La théorie de l’XP est relativement simple : comme écrire du code c’est compliqué, on arrive d’autant mieux à faire un code fiable quand celui-ci est vu par deux paires d’yeux, plutôt qu’une. Alors vous me direz : « mouahahaha, je suis assez grand pour faire mon code tout seul !« . Bon, alors voilà, on va causer de code compliqué qui doit être thread-safe et ensuite on en reparle, d’accord ?

Tout ça pour dire que même si l’XP ne se justifie pas nécessairement partout, dès que le code à écrire devient complexe d’une manière ou d’une autre il devient souhaitable. D’ailleurs même si ce n’est pas tout à fait ça dans de nombreux projets open source, les contributions de chacun sont relues par plusieurs personnes avant d’être intégrées.

La grosse différence ici est que les deux paires d’yeux observent les modifications du code en temps réel, ce qui permet de détecter au plus vite les erreurs. Or plus une erreur est détectée tôt, moins elle coûte cher à corriger. Le diagramme ci-dessous devrait vous éclaircir les idées.

Et alors, comment ça se passe dans la pratique

Comme dit plus haut, en XP il y a deux développeurs pour un seul clavier. Ce dernier fait office de ressource partagée, aussi il doit être utilisé en exclusion mutuelle. 😀

Plus sérieusement un des développeurs code effectivement sur le clavier, tandis que l’autre commente et explique ce qu’il faut faire. Rappelons que le deuxième programmeur n’a pas le droit de toucher le clavier, aussi pour expliquer les choses il est fortement recommandé qu’il ait un bloc-notes. Et régulièrement on inverse les rôles, à savoir que celui qui codait donne les instructions, et l’autre se met à coder.

Une pratique assez extrême…

Tel que défini plus haut, ça paraît facile. Dans les faits c’est quelque chose d’assez éprouvant à faire, et comme son nom l’indique, l’XP est assez extrême. Aussi il convient de prendre une pause de cinq à dix minutes toutes les heures. De même il n’est pas possible de pratiquer l’XP plus de sept heures par jour tant vous serez lessivés. Alors avis aux patrons : si vous demandez à vos développeurs de faire de l’XP, ne soyez pas surpris s’ils arrivent à 9h30 et partent à 17h : c’est normal, ils ne pourront pas faire plus !

eXtreme Programming et Test Driven Development : deux notions liées

On peut parfaitement pratiquer le Test Driven Development (TDD) sans faire d’XP. Par contre, pour l’inverse, autant le dire, c’est plus compliqué. En effet, comme on l’a vu précédemment, les rôles entre la personne qui code et la personne qui explique doivent être inversés régulièrement… mais c’est quoi régulièrement ?

En fait en appliquant le Test Driven Development (TDD) on résoud très simplement le problème, de la manière suivante :

1. Codeur 1 écrit un test unitaire suivant les demandes de Codeur 2. Ce test doit échouer.
2. Codeur 1 code la fonction de façon à ce que le test passe, sans casser de tests précédemment écrits concernant cette même fonction (eh oui c’est ça l’approche TDD), toujours en suivant les conseils de Codeur 2.
3. Une fois que les tests passent, on committe le code. Le TDD implique en effet de souvent committer, pour ensuite bénéficier du feedback rapide.
4. On inverse les rôles entre Codeur 1 et Codeur 2.

Une autre justification de l’utilisation du TDD en faisant de l’XP est tout simplement que l’intérêt de ce dernier est d’avoir un retour rapide sur ce qu’on code. Or les tests unitaires pratiqués à grande échelle permettent ce retour à l’échelle d’un projet. Donc il apparaît difficile de faire de l’XP sans TDD, pas vrai ? 😉

Les bénéfices de l’eXtreme Programming

Comme évoqué ci-dessus la pratique de l’XP permet d’améliorer la qualité du code. Mais son avantage ne se résume pas à ça.
En l’utilisant on peut aussi :

1. Permettre au petit nouveau du fond de monter rapidement en compétence sur un projet, en mettant en paire un développeur qui connaît bien un projet et le nouveau. Le premier permettra au deuxième de rapidement connaître le code et donc d’être plus rapidement opérationnel.
2. Permettre à chacun d’apprendre les bonnes pratiques de code. Le fait d’avoir des commentaires permanents sur ce qu’on est en train d’écrire permet d’échanger sur la manière idéale d’implémenter telle ou telle fonctionnalité, tant du point de vue code que du point de vue algorithmique.
3. … mais aussi travailler plus vite. En effet à deux on se distrait moins vite, mais c’est plus fatiguant.

En bref…

L’XP est idéal pour toutes les situations évoquées plus haut. Maintenant il convient de ne pas l’appliquer en permanence car il est très rapidement fatiguant. Aussi je conseille de l’appliquer quand le code devient complexe, ou pour favoriser les montées en compétence.

Mais comme tout pattern il convient de ne pas en abuser, sinon l’effet produit risque d’être l’inverse de ce qui était initialement souhaité. Les développeurs seraient lessivés. Or un développeur fatigué ne sera plus en mesure d’écrire du code de qualité. C’est pourquoi un développeur seul ne devrait pas dépasser huit heures par jour, tandis qu’en XP il sera déjà difficile d’atteindre les sept heures par jour.

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Les tests automatisés
• Soyez (vraiment…) agiles
• Comment un manager peut-il (bien) challenger un développeur ?

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn