Le bon matériel

Je soutiens l'appel qu'a fait Olivier Croisier sur son blog équipez vos développeurs et en ce sens j'affiche ce que coûterais divers ustensile utile pour mon travail suivant mon taux de facturation et le temps que je perds par jour à cause d'un build de l'application sur laquelle je travail (uniquement à cause de cela). image disponible sur le blog d'Olivier

Je parle en connaissance de cause car j'ai effectué les mêmes calculs qu'Olivier récemment sur mon projet, où nous somme sur windows 7 32 bits, avec des pentium duo core et un disque dur 5400 tours/minutes.

Le temps de build du projet sans les tests d'intégration était de 2minutes et 56 secondes.
Sur mon PC portable perso (un core i7, 16 Go de RAM, disque dur ssd 256 Go et Ubuntu 12 64 bits) le même build prenait 46 secondes !!!
Vous calculez plus de 2 minutes de perdus (toujours sans compter les tests d'intégration) par build, sachant que je fais plus d'une vingtaine de build par jour, je vous laisse vérifier c'est énorme.
Tout cela sans compter que lorsque votre machine mets plus de 4 minutes à builder votre application (la c'est en comptant les tests d'integ), vous ne rester pas à attendre derrière votre écran, vous faites autre chose (regarder ses mails, twitter, etc...) et ainsi vous perdez plus que les minutes nécessaires au build.

La réalité est pourtant que la plupart des développeurs, même s'ils expliquaient cela à leur client/hiérarchie n'auraient pas de meilleur matériel.
C'est pour cela que je réalise qu'il est nécessaire de choisir les gens avec qui ont travaille. Savoir si on préfère travailler avec des gens qui visent la qualité, l’efficacité dans le travail ou pas.
Qu'en pensez-vous ?

Moi je pair pas je gagne !

Après mon premier article sur le TDD, où j'ai remis en cause certains mythes sur le sujet, je m'attaque au Pair Programming, pratique soeur du TDD en eXtreme programming.

C'est la pratique XP qui a le moins de succès au sein de la communauté large de l'IT. On voit fleurir quantité de billet de blog pour dénigrer cette pratique, on lui préfère la revue de pair (faite par un chef, tu m'étonnes ...), on trouve cela stupide de dépenser deux fois le temps nécessaire pour faire la même chose.

Nous allons voir en quoi cette vision relève d'une incompréhension profonde de ce qu'est le pair programming et l'agile en général. Je vais essayer de briser quelques mythes et de montrer en quoi cette pratique donne toute son efficacité au TDD et à l'eXtreme programming.

TDD n'est pas tester !

Tu fais du TDD toi ?
Bah ouais, des fois j'écris mes tests en premier.
Et ton taux de couverture du code par les tests ?
Bah j'essaie d’atteindre les 80 %, y parait que c'est une bonne moyenne.
Souvent je rencontre des développeurs qui me parles du TDD comme cela.
Mais malheureusement il n'ont pas saisi ce qu'était le TDD, les objectifs qu'il permet d'atteindre, la façon de le mettre en œuvre.
Je vais essayer d'expliquer comment je vois et pratique le Test Driven Development, avec succès depuis quelques années.