Les tests mordent

vendredi 3 juin 2005 :: perrick :: Extreme Programming :: un commentaire :: aucun trackback

Hier pour accélerer l'exécution de la batterie de tests en lien avec la base de données. Nous -- en binôme -- avions mis un paquet d'entre eux en commentaire. Et puis le commit a eu lieu. Et puis un autre...

Ce soir je me rends compte que les commentaires sont toujours présent dans le code source. Et bien sûr un des tests ne passe plus. Rageant. D'autant plus que je ne retrouve pas si facilement d'où vient l'erreur. Encore un exemple du pouvoir du dévéloppement piloté par les tests. Et rappel pour moi-même : ils doivent passer tous, tout le temps. Y renoncer temporairement peut causer des dégats au moral et au début de week-end.

Les avantages de la programmation en binôme

mardi 5 avril 2005 :: perrick :: Extreme Programming :: 3 commentaires :: aucun trackback

Avec les scéances qui s'enchaînent, le temps passé en hack mode ou dans la zone s'allonge régulièrement. Le plus impressionant reste la facilité avec laquelle on revient dans cet état si précieux. Pendant une pause pipi, l'autre continue à écrire des tests ou à en faire passer : la synchronisation est très rapide. La télépathie s'y approche à grand pas. Blague à part, je me demande si certains ont vécu de telles sensations. Pour tous les autres avantages, un papier assez complet existe (mais en anglais) : It Takes Two to Tango.

Note à soi-même : surtout ne pas se laisser tenter par les emails qui arrivent au fil de l'eau. Non seulement la plupart sont du spam mais en plus ils n'intéressent pas le binôme. Depuis que j'ai récupéré mon portable avec une nouvelle carte mère et que le PC de développement ne sert qu'à ça, la différence est flagrante.

Les inconvénients de la programmation en binôme

jeudi 31 mars 2005 :: perrick :: Extreme Programming :: 4 commentaires :: aucun trackback

Depuis que le stagiaire -- T. -- de No Parking est arrivé, j'ai enfin pu me mettre à la programmation en binôme de façon systématique. Avec d'un côté l'auteur de 35 KLOC (la version en production d'openTIME) et de l'autre un étudiant en école d'ingénieur, le degré d'intimité avec le code existant est évidemment très mal réparti et donc les réflexes qui vont avec.

Par contre il y a un paramètre qui peut compenser la balance très rapidement : la fatigue ou plus simplement l'envie-de-rien-foutre-isme. Certains appelent cela plus prosaiquement le developer's block.

D'où ma question : comment faire comprendre à son binôme qu'un jour on a du mal à coder ?

Note : je ne dis pas ça pour aujourd'hui. On vient de faire passer tous nos tests pour générer l'affichage d'un calendrier (avec -- entre autres -- le plusieurs rendez-vous sur une même journée et en même temps pour une seule personne dont nous sommes particulièrement satisfaits ce soir : on verra demain si ça tient encore la route ;-).

Pendant que le vernis sèche, une ballade XP

dimanche 13 février 2005 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

Ce n'est pas souvent que je viens au bureau le week-end. Encore plus rarement pour y travailler à l'ordinateur : le plus souvent c'est pour du bricolage. Aujourd'hui c'est une nouvelle -- et grande : 2.50m de long par 1.8m de large -- table que je suis en train de vernir. Etant donné que j'accueille un stagiaire d'ici quelques semaines, il était grand temps de supprimer les simples "planches sur tréteaux". Les photos arriveront le jour où je me décide à acheter un appereil photo numérique...

En attendant je vous conseille d'aller faire un tour dans d'autres bureaux d'équipe de développement logiciel : Rachel Davies propose quelques retours intéressants sur des pratiques off-line de développement agile.

Et dans le baluchon de cette promenade dominicale et bloguesque, une phrase que j'aime beaucoup : Everybody on an XP team should feel like an idiot regularly. de Ken Auer et Roy Miller dans Extreme Programming Applied: Playing to Win via Red Squirrel.

Ecouter Kent Beck parler des tests développeurs

mardi 14 décembre 2004 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

J'avais découvert il y a quelques temps le site IT Conversations. Après m'être demandé quel était le meilleur moment & lieu pour écouter ce qui s'y passe, j'ai trouvé une piste intéressante : dans la cuisine de mon nouveau bureau il y a désormais une prise réseau + une paire d'enceintes. Il suffit donc de prendre son portable pour écouter Kent Beck "à la radio".

Pour ceux qui ne le savent pas encore, Kent Beck est un des piliers des mouvements "Extreme Programming", "développement piloté par les tests", "remaniement permanent", etc. Dans sa conférence "Developer Testing" il introduit une notion très intéressante : celle de la santé d'un logiciel. Il s'agit de sa résistance au stress (comprendre à l'usage, aux modifications ultérieurs, à la montée en charge, etc.). Pour les autres points à y glaner -- entre autres : responsabilité du développeur par rapport à son logiciel, pas de différence entre tests unitaires et tests fonctionnels, tests développeur comme feed-back immédiats -- je vous invite à l'écouter directement.

TDD : des chiffres qui font réfléchir

mardi 19 octobre 2004 :: perrick :: Extreme Programming :: 2 commentaires :: aucun trackback

L'avantage de commencer en TDD, c'est que le nombre de tests suit très régulièrement le nombre de ligne du code source à proprement dit. Toujours suite au petit exercice lors du dernier groupe de praticiens XP à Paris, j'ai lancé ma calculette pour les 2 heures de développement :

De côté d'openTIME, le ratio est un peu différent : 79.148. Autrement dit je suis encore très loin du compte. Mais quel progrès par rapport à mes premiers balbutiemment (261.782 au mois de mai)... C'est ce qui s'appelle être Test Infected.

Le TDD par l'exemple

:: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

Pour une piqûre de rappel, la dernière scéance de TDD (Développement Piloté par les Tests) avec le groupe des praticiens XP parisiens fut très intéressante. Outre une démonstration de ce qui se passe dans openTIME à ce niveau-là, ce fut surtout l'occasion de se frotter à SimpleTest un peu plus en profondeur. Notre proposition -- avec David Bonnet -- pour le jeu du frigo est en ligne. Et elle peut (pourra) être comparer à d'autres tentatives, en Ruby ou en PHP.

Dans les leçons retenues -- en passant sur le fait que je n'ai toujours pas goûté à Ruby -- je retiendrai quand même une chose d'inattendu : les 4 autres binômes auront réussi une fois en deux heures à me "sortir de la bulle" -- avec cette folle envie de crier je n'arrive pas à me concentrer : merci de faire moins de bruit s'il vous plaît. Par contre je ne sais pas si c'est un succès (une fois ce n'est pas beaucoup) ou un échec (10 personnes + 1 client étant la taille "idéale" d'une équipe XP, une fois c'est une de trop).

La couverture de tests unitaires avance

jeudi 23 septembre 2004 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

En avril 2004, je commençais à mettre en place mes premiers tests unitaires sur openTIME : il s'agissait à l'époque de quelque chose de tout nouveau pour moi. Je n'en avais jamais entendu parlé à la fac (où j'ai fait principalement des maths, plus une touche d'informatique -- Mathematica et C). Et puis il y a eu le site http://www.extremeprogramming.org/ où je les ai vu -- à défaut de les comprendre -- pour la première fois, vers 2000 / 2001. Et au final un livre, mais ça c'est une autre histoire.

Et aujourd'hui j'ai enfin mes premiers tests unitaires en lien direct avec la base de données. Pour y arriver je me suis largement inspiré des efforts de Cédric -- alias plcoder : MyUnit.

Parmi les effets bénéfiques de cette couverture de tests unitaires, je note en particulier :

Pour ceux qui parlent anglais un post récent -- il date de ce jour ;-) -- de C. Keith Ray propose ses 8 Reasons to do Unit Testing / TDD / Automated acceptance tests. Pour les autres je vous conseille un petit tour sur le Wiki d'XP-France.

Les méthodes agiles marchent... La preuve par PHP

lundi 3 mai 2004 :: perrick :: Extreme Programming :: 4 commentaires :: aucun trackback

Dans un billet récent, Martin Fowler se posent la question de savoir si les méthodes agiles marchent même avec des développeurs "moyens". John Lim répond très logiquement : le développement Open Source est une méthode agile. Or beaucoup de développeurs PHP ne sont pas informaticiens. Et beaucoup de projets Open Source sont développés en PHP. Donc les méthodes agiles marche pour beaucoup de développeurs "moyens".

En tant que développeur PHP et praticien aussi agile que possible, j'ai aussi l'impression que les qualités d'un bon développeur "agile" ne sont pas nécessairement dans son bagage informatique mais bien dans son bagage "humain". Ecoute, communication, échange, courage, etc. ne s'apprennent pas toujours dans les cours d'informatique ! Reste donc à savoir plus précisement ce qu'on entend par average or below average developers ?

Etymologie et définition du Coach XP

mercredi 21 avril 2004 :: perrick :: Extreme Programming :: 3 commentaires :: aucun trackback

Le thème du dernier groupe de praticiens XP auquel j'ai pu participer était la notion "coach XP". Et comme tout mot issu de nos cousins anglo-saxons et importé par des techos pur jus, la traduction apporte souvent son lot de confusion.

En cherchant une étymologie, j'espérais conforter mon intuition que le coach n'est pas un "homme sage" (qui prodigue des conseils) mais plutôt une "sage-femme" (qui assistance à l'accouchement).

Un petit tour sur le wikipedia pour découvrir : [ma traduction] Le mot coach vient du mot hongrois pour diligence, kocsi. Kocs est une petite vile en Hongrie où furent construites - au Moyen Age - des diligences postales avec un système de suspension et de conduite à la fois innovant, exceptionnellement solide et confortable.

Reste à trouver la traduction la plus proche en français : "entraineur" (qui dirige, qui exerce une influence dominante sur quelqu'un, qui mène), "animateur" (qui donne une âme) ou autre chose encore.

Conférence eXtreme Programming

dimanche 11 avril 2004 :: perrick :: Extreme Programming :: 2 commentaires :: aucun trackback

Mes débuts en eXtreme Programming portent des fruits parfois inattendus : je pensais avoir un code propre et avec le moins de bugs possibles. Et voilà-t-il pas que je participe à la table ronde sur PHP et XP organisé par l'AFUP. Un court résumé de cette présentation menée par Laurent Bossavit est disponible sur le site de l'AFUP.

Premier pas vers l'Extreme Programming

jeudi 18 décembre 2003 :: perrick :: Extreme Programming :: 4 commentaires :: un trackback

Pendant le forum PHP, j'ai récupéré un bouquin sur l'Extreme Programming que j'ai dévoré. Par contre je suis seul à développer sur openTIME -- donc pas possible de faire de la programmation à 2. Même chose pour toutes les recommandations où il faut être en équipe avec des rôles bien assignés.

Et pourtant je m'astreins à créer un test unitaire à chaque découverte de bug et à chaque étape de refactoring. Et aujourd'hui ça a payé : j'ai pu découvrir deux bizarreries à partir de mon test d'origine. Le genre de bricoles qui marchent quand même parce que je suis en local mais qui une fois sur un serveur de production peuvent rendre perplexe.

Et un lien que je n'ai pas encore exploré sur le sujet : http://xp-france.net/cgi-bin/wiki.pl.

<< 1 2