Il y a une semaine, Drealmer me proposa de faire une expérience amusante, tester le binômage à travers Internet. Je trouvais l’idée vraiment sympa et c’était le moment idéal pour faire un peu de programmation par les tests (TDD) sur un exemple simple.
Le but de l’exercice était de faire une fonction prenant un nombre romain (XI) et le converti en nombre arabe (11).
Voici le retour d’expérience après 3 heures de binômage web :

Ce qui s’est bien passé

TDD

C’était la première fois que l’on faisait réellement du TDD, c’est à dire coder les tests avant la fonctionnalité. On ne pensait pas que l’exercice serait suffisamment complexe pour mettre en évidence l’intérêt de cette pratique mais on avait tout faux ! Apres environ 2h de TDD et un assez gros refactoring, la moitié de nos tests ont échoué. Surprise, on ne pensait vraiment pas avoir pu ajouter un bug par le changement que l’on venait de faire. Rapidement, les tests ont permis d’isoler l’élément déclencheur, et l’erreur fut repérée et corrigée. Sans les tests, on n’aurait sûrement pas détecté le bug immédiatement, ce qui aurait augmenté la difficulté pour l’isoler.

Apprentissage continu

Un des intérêts du binômage est le passage de connaissances. Faire binômer un débutant et une personne expérimentée est le meilleur moyen pour le débutant d’apprendre beaucoup de choses, rapidement et sans pour autant faire perdre du temps à l’autre. Dans notre cas, la différence de niveau était beaucoup moins importante mais 3h de binômage ont permis à chacun d’apprendre de nouvelles choses.

Drealmer : j’ai appris une petite astuce de Visual C++, si on envoie dans la fenêtre de log (via OutputDebugString) des chaînes formatées de la même façon que les warnings et erreurs du compilateur, cela permet de directement accéder à un endroit précis du code par un simple double-clic. La syntaxe pour ce faire est “__FILE__(__LINE__): assert failed”, qui donne des résultats de ce type : “C:\code\main.cpp(52): assert failed”. Très pratique pour les asserts, les erreurs, les unit tests…

Ace : Il est souvent pratique d’avoir une fonction de log simple pour débugger et afficher facilement des informations. J’ai toujours utilisé le système des paramètres variables pour le faire, par exemple : log(“fps: %f”,fps); Sauf que je n’avais pas pensé à utiliser les stream c++ associé à une macro permettant de faire: log(“fps: ” « fps);

Echanges

L’idée du pair programming étant de se partager une unique machine, il est important que les participants l’utilisent à tour de rôle et non pas en même temps. Mais aussi que “la main” passe de l’un à l’autre assez fréquemment, pour garantir l’implication des partenaires. Le problème lorsque l’on tente l’expérience à distance est que l’on n’a pas de repère visuel pour déterminer quand l’autre programmeur veut intervenir. Heureusement, après quelques petites “collisions”, nous nous sommes rapidement disciplinés à demander son tour avant d’intervenir, et l’exercice s’est déroulé sans encombre et à un bon rythme. Il était courant de prendre le clavier juste 30 secondes pour changer quelque chose et de le rendre aussi tôt.

Concentration

Gros effet positif du pair programming, qui se ressent rapidement, chacun est incité à suivre le rythme de l’autre et ne se laisse pas distraire comme il pourrait l’être s’il était seul. Tout simplement le fait d’avoir le même écran devant les yeux fait que l’on évitera systématiquement tout ce qui est personnel, à savoir email, pager, forum, etc. Du coup on est beaucoup plus efficace, mais la fatigue s’installe plus vite.

Ce qui s’est mal passé

Les problèmes étaient surtout d’ordre technique et de préparation.

Communication orale

Il est clair que le chat en texte n’est pas suffisant, un moyen de communiquer oralement est indispensable, il faut donc des casques, des micros, et un système comme Skype.Étant donné la mauvaise qualité du casque-micro de l’un des participants, la communication dans un sens a souffert d’un bruit de fond assez pénible. La compréhension n’en a pas souffert, mais le confort d’utilisation, oui. A l’avenir, un petit investissement sera probablement nécessaire à ce niveau. Il est à noter que le casque n’est probablement pas le seul responsable, car même débranché la carte son capte un grésillement. Camelote.

Communication visuelle

Pour pouvoir programmer ensemble, il faut pouvoir interagir sur le même programme et donc partager son écran.Malgré de nombreux essais, TightVNC n’a jamais fonctionné de façon satisfaisante que dans un sens. Sur l’une des machines utilisées pour le binômage, la présence du serveur induisait de fréquents freezes de l’interface, rendant la machine ingérable pour les deux participants. Nous n’avons aucune idée sur l’origine de ce comportement.

Ne pas se voir

Le fait de ne pas se voir diminue l’information disponible et rend les choses moins évidentes. Par exemple, lorsque l’autre ne parlait plus on ne savait pas s’il réfléchissait ou s’il était parti sortir les poubelles. On était donc toujours en train de parler et on se focalisait uniquement sur le code. Il aurait été intéressant que la personne qui ne programmait pas se concentre sur des aspects de plus haut niveau.

Conclusion

À l’issue de l’exercice, un programme fonctionnel avait été réalisé, contrôlé par 32 tests, ce qui faisait environ un test pour trois lignes de code. On peut donc considérer l’objectif atteint. Cependant, un bref coup d’oeil sur Internet nous a permis de trouver une approche bien plus efficace et élégante. Problème de refactoring pas assez poussé ? Développement (trop) itératif ? En fait, toute méthode de travail, aussi efficace soit-elle, ne dispense pas de bien réfléchir avant de coder. Dans notre volonté de centrer l’exercice sur le TDD nous avons négligé cet aspect.
Quoiqu’il en soit, le binômage par Internet est tout à fait possible, du moins dans le cadre de petits projets. Il faudra trouver autre chose que TightVNC pour s’attaquer à de plus gros problèmes, et à des systèmes nécessitant un affichage graphique. Cependant, il ne faut pas négliger le temps requis pour la mise en place et l’essai des logiciels nécessaires.

Binômage sur Internet pour la rédaction d’un ticket

Après cette expérience réussie de programmation en binôme sur le Internet, on a voulu faire la même chose pour rédiger le compte rendu. L’article que vous avez donc sous les yeux a été rédigé en “pair writing on the Internet”.

Nous avons essayé différents éditeurs de texte collaboratifs. Nous tenions à ce que l’outil soit en temps réel, et cela limite fortement le choix. Au final, gobby est celui qui nous a semblé le plus fonctionnel. Ecrit en GTK+ il souffre de quelques bugs graphiques, et la coloration du texte en fonction du rédacteur a tendance à partir en vrille au fur et à mesure de l’édition, mais ça reste utilisable. Le plus gros inconvénient restant le manque de fonction annuler ! Cependant, il est suffisant pour l’usage que nous en avons eu, qui était de pouvoir écrire différents paragraphes simultanément, et de se relire l’un l’autre.

Le principal intérêt qui s’est dégagé de notre expérience d’écriture collaborative est qu’afin de pouvoir se répartir le travail efficacement, il est indispensable de structurer le texte à rédiger avant de s’attaquer à la forme. Ce qui a pour effet de dégager les idées conductrices de façon plus dynamique, ce qu’un traditionnel échange par email n’aurait peut-être pas réussi à faire, ou en tous cas pas aussi rapidement. Il serait intéressant de voir ce que cette approche permettrait de faire dans un cadre créatif (nouvelle, roman).

Voici un compte rendu de personnes ayant aussi tenté l’expérience du pair programming par Internet.