index.md 4.4KB
title: Code reviews croisées slug: code-reviews-croisees date: 2016-06-20 chapo: Je vois cela comme de la pollinisation technique, un moyen de faire monter en compétence et en curiosité ses pairs.
« Le processus de rationalisation donne ses pouvoirs à l’expert, mais les résultats de la rationalisation les limitent. Sitôt qu’un domaine est sérieusement analysé et connu, sitôt que les premières intuitions et innovations ont été traduites en règle et programme, le pouvoir de l’expert tend à disparaître. En fait les experts n’ont de pouvoir social réel que sur le front du progrès, ce qui signifie que ce pouvoir est changeant et fragile… », et leur pouvoir serait de plus en plus fragile « dans la mesure où les méthodes et programmes auxquels science et technologie parviennent peuvent être utilisés et dirigés par des gens qui ne sont plus des experts… »
Jacques Ellul dans L’illusion politique citant Crozier dans Le phénomène bureaucratique
J’ai fait appel à Anthony pour faire une revue de code sur un bout de JavaScript que j’estimais de faible qualité. La semaine précédente, Stéphane nous demandait avec David d’effectuer une revue de code plus haut niveau sur le code de MultiBàO. Ces code reviews croisées permettent d’augmenter la qualité d’un code de façon impressionnante. La pratique de la revue de code dans le cadre d’une collaboration technique au sein d’une équipe peut mener à une certaine monotonie mais le simple fait de demander à quelqu’un d’externe permet de prendre du recul sur la pertinence de ce que l’on a développé, sur sa compréhension par un nouveau venu et sur la façon que l’on a de le tester. Je vois cela comme de la pollinisation technique, un moyen de faire monter en compétence et en curiosité ses pairs.
La revue de code en elle-même m’a permis d’identifier certains patterns dans ma façon de coder et d’être plus vigilant sur ces points à l’avenir. C’est une chose qui est déjà identifiable au sein d’une équipe mais qui tend à être moins remontée à la longue par habitude et manque d’attention. Autre problématique que l’on a en interne, on est trop peu nombreux pour pouvoir imposer plusieurs revues par pull-request ce qui endommage la qualité, idéalement je pense qu’il en faudrait deux ou trois. Enfin un œil nouveau permet de revoir la façon de documenter le pourquoi ce qui est difficile lorsque toute l’équipe sait de quoi est-ce qu’il est question.
Ces expériences me donnent envie d’aller plus loin dans ces échanges croisés. Est-ce qu’il faut vraiment essayer de passer à l’échelle ? Est-ce qu’il faut une charte (bienveillance, respect, etc) ? Est-ce qu’une monnaie virtuelle est nécessaire pour ce troc ? Est-ce qu’il faut un service pour centraliser l’index ? (DAO (cache) ? :-p) Est-ce que d’autres personnes seraient intéressées ? Est-ce que d’autres projets auraient le même besoin ? J’ai encore beaucoup de questions sur le sujet mais je sais que je peux déjà m’engager à titre personnel sur 2 à 3 revues Python/ES6 sur ces prochaines semaines si vous êtes motivés. Un bon moyen de tester la formule. La seule contrainte que je me mets c’est de pouvoir le faire sur du code en open-source sur cette première itération. Envoyez-moi vos PR/MR/autres ! :-)
Mais M. Crozier me semble assimiler à tort l’expert et le technicien. Sans doute l’expert est appelé, incidemment, pour donner son avis dans une situation d’incertitude. Mais le rôle du technicien, qui d’ailleurs peut aussi être appelé comme expert, ne se limite pas à cela. Or, ce n’est pas parce que la situation cesse d’être incertaine que l’influence du technicien diminue. Et nous sommes très loin d’une diffusion aisée et simple des techniques !
Ibid.
Anthony me signale en meta-review ce qu’avait fait Tarek à ce sujet (cache).