Message à mes coéquipiers concernant la qualité de notre code

J'ai adressé cette lettre à mes coéquipiers dans l'espoir de faire monter d'un cran le niveau de qualité du code que nous écrivons. Pour le contexte, cette lettre est la réponse à un problème d'engagement que notre patron soulevait par rapports à nos meeting de scrum (un processus de gestion de projet) mais qui avait des ramifications plus profondes, comme on peut le constater plus bas. Je suis fier de cette lettre car je trouve qu'elle résume bien la situation, et que par celle-ci, je fais preuve de leadership.

On ne peut pas être contre la vertue. C'est évident que je suis d'accord avec toutes les propositions pour le scrum.

Toute cette réflexion par rapport à notre identité et notre rôle d'ingénieur logiciel m'a fait réfléchir sur notre travail. Je dois vous admettre que quelque chose me dérange dans notre façon de travailler. Ce n'est pas un blâme, parce que, d'abord, je suis le premier à admettre que j'ai besoin d'aide pour produire du code de qualité. Ceci étant dit, je trouve que la qualité du code qu'on livre, en général, laisse beaucoup à désirer. Le premier indice (bad smell) qui nous indique nous avons un problème, c'est la clarté, la lisibilité et la maintenabilité de notre code. Les métriques de qualité comme la maintenabilité et la clarté sont très difficile à mesurer. Mais pensez seulement aux nombre de fois, qu'on se demande qu'est-ce que fait une méthode, qu'est-ce que fait tel test, pourquoi est-ce que telle variable existe, pourquoi avoir choisi ce design... pourquoi les tests sont aussi difficiles à maintenir. Je pense qu'il faut avoir l'honnêteté intellectuelle d'admettre qu'on a de la difficulté. C'est seulement une fois que nous aurons admis cela que nous pourrons avancer. Ceci étant dit, j'ai quelques solutions à proposer :

Ownership du code et responsabilisation

Nous devons tous avoir l'impression que le code nous appartient. Nous devons nous sentir responsable de ce qu'on fait ET de ce que les autres font. Quand quelqu'un constate qu'une partie du code n'est pas à la hauteur, il faut que ça nous fasse quelque chose. Est-ce que ça ne vous choque pas de voir du code tout croche ? N'avez-vous pas l'impression que c'est intolérable de produire du code tout neuf qui est déjà indéchiffrable et mal conçu ? Il nous faut tous ressentir ça. C'est la conséquence directe de la possession de quelque chose. Quand ce quelque chose nous appartient, on veut en être fier et on veut l'entretenir. Excuse-moi Hugues, je sais que tu n'aimes pas être en vedette mais je vais te prendre en exemple. Tout comme Hugues, il faut qu'on ait tous la rage de rentrer dedans et refactorer sans pitié. Je le sens que Hugues a autant à coeur l'entretient du code que l'entretient de sa maison, parce que, pour lui le code est sien.

Ce qui m'amène à mon second point.

Peer pressure

Je crois que nous sommes beaucoup trop complaisants envers les erreurs. Pas les nôtres ! Celles des autres. Nous n'avons aucune difficulté à admettre nos erreurs , mais encore faut-il être capable de les identifier. Pour cela, le regard des autres est très utile. Par contre, il semble que nous ayons beaucoup plus difficulté à parler des erreurs des autres que des nôtres ! Comment peut-on apprendre si on ne se corrige pas mutuellement. Les collègues doivent absolument pouvoir servir de miroir, pour que l'image qu'ils nous renvoient de nous-mêmes et de notre travail, soit juste. Ce n'est pas notre boss qui va nous corriger sur le code, il ne code pas. Je vais citer un article que je viens de lire concernant les builds pétés:

One of the best solutions to the problem of people not checking their code before they check it in is peer pressure. Anyone who checks in code without compiling it first ought to feel embarrassed by such a mistake, and if not, the other people around them should strongly encourage them to feel embarrassed. Shame, it turns out, is a strong motivator for avoiding antisocial behavior. Like many—or perhaps all—of KV's suggestions, shaming can be taken too far, but I suggest you try it and see how it works.

Depending on Mommy to tell off the misbehaving kids becomes tiresome both for you and the project management after a while. What you want to see is a good working culture develop, one in which people know that breaking the build is like taking a dump in the middle of the break room; funny once, but usually unacceptable.

Je pense que ceci s'applique également à nous. Si on ne réagit pas lorsqu'on voit des conneries, on ne sera pas émotivement affecté et on cela ne nous poussera pas à changer nos mauvaises habitudes. Je crois franchement que s'il est vrai qu'on est une équipe, il faut être solidaire et être engagé et ça passe par le peer pressure. Mais pour avoir envie d'appliquer le peer pressure, il faut avoir à coeur la qualité du code qu'on produit donc l'étape 1 (ownership du code) est un prérequis. Pour favoriser le ownership du code, il faut touchez à toutes les parties du code et participer aux refactor des parties qui nécessitent d'être améliorées.

Ce qui m'amène à ma dernière suggestion.

Pair programming

L'expérience que j'ai gagnée à programmer en paire (en jumelage?) est incalculable et cela s'est confirmé en le faisant avec Hugues depuis 2 jours. Je propose donc que nous pair programmions à tour de rôle en rotation ET/OU qu'Hugues pair programme à tour de rôle avec chacun d'entre-nous. Parce que je crois que grâce à son expérience, il peut apporter beaucoup à l'équipe en nous montrant étroitement comment il pense/travaille.

Voilà,

C'était ma montée de lait. Merci Pascal pour ton rappel à l'ordre. J'ai saisi l'opportunité au vol parce que tout ce dont je viens de parler, c'est aussi ça le professionnalisme et c'est aussi ça, être ingénieur logiciel.

Merci

Martin