Egoless Programming Manifesto

Lors de la keynote de Pierre Piezardi à Devoxx France 2012, il a été fait mention du manifeste Egoless Programming. Cela m'a tout de suite frappé et intéressé.
Cette collection cohérente de "règles de vie" du développeur est une pierre utile à l'édifice "AGILE", une façon d'incarner ces valeurs.

1. Comprendre et accepter que nous pouvons faire des erreurs
2. Nous ne sommes pas notre code
3. Peu importe combien nous connaissons le karate, il y aura toujours quelqu'un qui en connaîtra plus que nous
4. Ne pas réécrire le code d'un autre programmeur sans le consulter avant
5. Traitons les gens qui en savent moins que nous avec respect, déférence et patience
6. La seule constante dans le monde est le changement
7. La seule vrai autorité vient du savoir et non de la position
8. Battons-nous pour ce que nous croyons mais acceptons gracieusement la défaite
9. Ne soyons pas "the guy in the room"
10. Critiquons le code plutôt que le codeur. Soyons gentil avec le codeur, pas avec le code

Pourquoi tu programmes ?

Pourquoi programmons nous ? Je ne pose pas la question dans un sens existentiel ou motivationnel.
A travers cette question je cherche à faire apparaître un sens à ce que nous faisons, pour la plupart de nous, plusieurs heures chaque jours.

Functional Programming Principles in Scala - Les certifications sont arrivées

Pour ceux qui ont participé à la classe Functional Programming Principles in Scala sur Coursera, les "certificats" sont publiés sur votre page profil dans le menu "Course Records".

Le mien :

Smarter pojo

Je vous ai montré, dans un article précédent, comment écrire un pojo immuable fournissant une API d'instanciation sémantique. Dans ce premier article sur Scala, je vais montrer comment faire de même et ceci beaucoup plus simplement, grâce aux concepts et aux différents sucres syntaxiques fournit par le langage.

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.