Autre

La programmation en tant qu’Art Martial

Il y a quelques années j’ai eu la chance de participer au Dojo de Programmation de Paris. L’idée consiste à aborder la programmation à la manière d’un art martial.  Plutôt que de s’attaquer directement aux problèmes du monde réel, on commence par s’entrainer inlassablement sur des sujets simples jusqu’à trouver le geste parfait.

Concrètement un Kata c’est un exercice de programmation respectant un ensemble de règles imposées d’emblée. En principe il s’agit de suivre les bonnes pratiques de programmation, en particulier le TDD.

Dans le cadre du Dojo de Paris voici les règles que nous pratiquons :

  • La session commence généralement par une restrospective des séances précédentes, ce qui était bien, ce qui l’était moins, etc.
  • Les participants sont libres de proposer un sujet, préparé ou non. Le sujet est normalement présenté sous la forme d’une User Story, incluant un test de recette. Le langage de programmation utilisé fait partie du sujet. Il est déconseillé que le sujet abordé soit d’une utilité immédiate pour un travail en cours. Il est parfaitement acceptable et même recommandé qu’un sujet de kata soit très simple, ou déjà traité dix fois lors de sessions précédentes. Il est parfaitement acceptable de choisir un sujet dans un language de programmation qu’on est en train d’apprendre, voire qui nous est totalement inconnu (mais dans ce cas, il est préférable que quelqu’un le connaisse dans l’assistance ou de disposer un d’un accès Web ou d’un livre de référence). On évitera de partir à la fois sur un nouveau sujet et un language inconnu, le résultat risquant d’être quelque peu frustrant.
  • Le choix du sujet est mis au vote par les participants au début de la session, chacun ayant 3 voix à répartir
  • On décide également du temps qui sera consacré au kata, normalement pas plus d’une heure ou une heure trente.
  • Une paire de programmeurs – pilote et copilote – est au clavier, les autres sont le public (il est recommandé de disposer d’une salle avec projecteur d’écran ou écran géant pour que le pblic puisse suivre dans de bonnes condition).
  • Les codeurs peuvent éventuellement commencer par implémenter le test de recette (ou bien ils ne le feront que lorsqu’ils considéreront l’implémentation comme assez avancée).
  • On propose un test, le plus simple possible, qui pertmet d’avancer vers la solution du problème.
  • On programme le test et on s’assure qu’il échoue. Si le test n’échoue pas, c’est un mauvais test et il faut en trouver un autre, celui qui l’a proposé est soumis à l’opprobe publique (mais un mauvais test éclaire souvent sur un aspect du code à clarifier).
  • On écrit le code nécessaire pour faire passer le test, qui lui aussi doit être le plus simple possible
  • On regarde le code pour appliquer les refactoring éventuels nécessaires, typiquement en reniflant les mauvaises odeurs. Les plus communes sont classiquement la duplication de code et l’usage de faux (constantes magiques injectées pour faire passer les tests).
  • A tout instant le public peut intervenir pour proposer un test ou une implémentation plus simple, suggérer un refactoring, ou toute autre remarque utile. Le public est actif et au même niveau que les codeurs, ce n’est pas un simple auditoire.
  • Si le public ne comprend plus le code ou la progression du Kata, il *doit* intervenir et demander des éclaircissements aux codeurs. Le but est d’atteindre l’illumination pour tous les participants, si ce n’est pas le cas le Kata est un échec. Chaque participant devrait pouvoir refaire le Kata par lui-même à l’issue de la session.
  • Le sujet est considéré comme traité s’il n’est plus possible de proposer un test qui échoue.
  • Lorsque le temps consacré au Kata est écoulé, on arrête l’exercice, quel que soit l’état d’avancement.
  • On arrête également si le sujet est entièrement traité. S’il reste du temps on peut également explorer des voies alternatives, ou prolonger le sujet. Notons qu’il est d’usage de faire une pause à mi-temps, voire plusieurs pauses pour des sessions longues.
  • A la fin du Kata quelques minutes sont consacrées à une discussion sur le Kata, ceci peut éventuellement se faire au café ou au restaurant le plus proche, les participants ayant proposés trop de mauvais tests (qui passent immédiatement)  payant éventuellement la tournée.

Sur cette base toutes les variantes sont possibles, par exemple l’ajout de règles arbitraires. Le randori est une autre variante amusante, ou les codeurs tournent à intervalle régulier, le co-pilote devenant pilote et choisissant un nouveau copilote. Les détails varient évidemment en fonction du contexte. Il est clair qu’un kata présenté devant un amphithéatre de 300 personnes sera moins interactif qu’une session intimiste avec 5 participants. Le kata peut même se pratiquer en solitaire.

Sur ce blog j’ai l’intention de présenter des compte rendus détaillés de Katas de programmation, avec le chemin suivi et les commentaires correspondants, ceci avant tout pour mon propre usage. Mais tant mieux s’ils sont utiles à d’autres. N’hésitez pas à proposer des sujets.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s