La peer review à l'école

J’adore Github. Je l’aime tellement – malgré tout le mal que j’en pense – que j’ai pris un compte payant à titre personnel afin de les remercier de toutes les ressources qu’ils mettent gratuitement à la disposition de mes projets open source.

Git en lui-même est un excellent outil. Github (ou Gitlab si vous travaillez chez OVH) l’étend et apporte la possibilité de créer des workflow de travail très simple autour de lui. Il en existe de nombreux, Gitflow étant probablement le plus connu, mais tous incluent une composante fondamentale : la peer review.

Chez Botify, nous utilisons un workflow à la fois simple, et efficace :

Workflow git

  1. Brad crée une issue dans Github. Il affecte l’issue, à Bob ou à lui-même, en fonction de leurs compétences et de leur charge de travail respectives (je simplifie volontairement cette partie).
  2. Brad crée une branche dans git sous le nom feature/ce-que-je-vais-faire/123123  est le numéro de l’issue dans Github. Si c’est un bug, la branche s’appelle bug/ce-que-je-vais-faire/123. En travaillant sur une branche à part, Brad s’assure qu’il ne modifiera pas le code commun considéré comme stable, et que son travail ne rentrera pas en conflit avec celui de ses petits camarades.
  3. Brad fait ce qu’il a à faire, commit, et crée une pull request. La pull request, c’est une manière de dire aux autres <q>hep, j’ai fait ça, c’est dans une branche, j’aimerais bien que quelqu’un le valide et l’intègre au projet principal</q>.
  4. Bob relit le travail de Brad. S’il n’a rien à rajouter, il valide la pull request et la merge dans le code commun. Dans le cas contraire, il laisse des commentaires à Brad qui part revoir sa copie. C’est cette dernière partie qu’on appelle la peer review.

La peer review, c’est une revue critique du travail d’un collègue à des fins d’améliorations. Elle porte à la fois sur le fond et sur la forme, et couvre aussi bien l’exactitude du travail délivré que le respect des guidelines maison ou les possibles améliorations à apporter.

Le peer, ou pair en français introduit une notion d’égalité entre celui qui revoit et celui qui est revu, indépendamment de la structure hiérarchique de l’entreprise. Je peux très bien effectuer une revue sur le travail d’un de mes supérieurs, et si je trouve des choses à y redire, le renvoyer à sa copie. La revue peut être effectuée indépendamment par une ou plusieurs personnes : plus on est de fous, moins y’a de riz.

La notion de peer review est très ancienne. On la fait remonter au haut Moyen-Âge, même si l’on ne trouve pas de preuve formelle de son existence avant le XIVème siècle.

Avant l’avènement des Capétiens, le roi était élu parmi les pairs de France, il devenait à ce titre primus inter pares, c’est à dire le premier d’entre les égaux. Le roi et ses pairs avaient coutume de s’épauler les uns les autres en soumettant les grands pans de leur politique respective à une critique mutuelle.

La réunification du royaume de France par les successeurs d’Hugues Capet a rapidement fait tomber cette notion en désuétude, même s’ils ont continué à se prodiguer aide et conseil jusqu’aux débuts de l’absolutisme. L’expression peer review est elle-même apparue en 1325, lorsque Philippe Le
Bel convoqua son gendre Edouard II, roi d’Angleterre et duc de Normandie (et donc, à ce titre, paire de Couilly) pour lui dire tout le mal qu’il pensait de lui. En sortant de cette entrevue, Edouard II aurait dit à son favori Hugues le Despenser dans un anglais en formation encore mâtiné de français: Oh my gode (le roi affectionnait particulièrement la quenouille), c’est la pire review qu’on m’ait jamais faite !

L’expression était née, mais il a fallu attendre 1637 pour que René-Gilles Descartes en formalise la théorie dans un chapitre depuis expurgé de son Discours de la Méthode, Pour bien conduire sa raison, et chercher la vérité dans les sciences depuis réédité sous le titre beaucoup plus populaire de La Méthode à Gilles.

Tout ceci est historiquement authentique (référence souhaitée).

Si j’avais un seul conseil à donner à notre sinistre de l’éducation nationale, ce serait d’habituer les enfants au peer reviewing le plus tôt possibles :

  • ça développe l’esprit critique au lieu d’en faire des béni oui oui.
  • ça leur évitera de pleurnicher quand plus tard on leur dira de refaire leur travail.

Ces dernières années, je n’avais aucun vis à vis pour me renvoyer à mes copies quand je délivrais quelque chose d’insuffisant, et je me rends compte à quel point ça m’a manqué. Il fallait que ça marche, et c’était le principal.

Parce que la première fois, ça pique. Nous étions pourtant aux antipodes des peer reviews de Linus Torvalds, mais intérieurement, ma réaction a peu ou prou été “j’ai fait de la merde, je n’ai pas le niveau et il me le fait comprendre”.

La seconde fois, ça pique encore : j’étais plutôt sûr de moi – trop – mais j’avais des remarques à peu près une ligne sur deux. Non seulement ces remarques étaient justes, mais mon travail était effectivement très perfectible.

La troisième fois, le lendemain, ça a de nouveau piqué. Fort. Me faire renvoyer à ma copie deux fois en 24 heures a recommencé à me faire sérieusement douter de mes capacités techniques, et de la différence entre la personne qu’ils pensaient avoir embauché et celle qu’ils avaient embauchée, syndrome de l’imposteur, tout ça tout ça.

Tout ça, c’était de la connerie et de l’ego mal placé. Parce qu’une fois remisé le pic, le cap, que dis-je le cap la péninsule qui me sert d’ego, ça a été un des trucs les plus géniaux qui me soient arrivés depuis longtemps.

La peer review, ce n’est pas dans un seul sens. Greg et Théo font des revues de mon travail, et moi du leur. Comme ils sont bons, j’apprends beaucoup, et… c’est fun. Les premières semaines, j’avais surtout fait des remarques sur le forme, mais je n’étais jamais vraiment rentré au fond des choses. Jusqu’au jour où…

Et bien jusqu’au jour où j’ai commencé à me poser les bonnes questions :

  • Est-ce qu’il n’y a pas moyen de simplifier ça ?
  • Qu’est-ce que ça a comme conséquences sur le reste du code ?
  • Est-ce que ça n’ouvre pas la porte à un gros et intéressant refactoring ?

Du coup, je suis parti plonger dans la doc à la recherche de quelques détails importants – c’est comme la pomme et la betterave, y’en a, et en moins de temps qu’il n’en faut à un adolescent pour éternuer dans son mouchoir, j’avais appris une demi-douzaine de trucs. Des trucs utiles.

C’est le premier avantage de la peer review bien bien faite : on apprend plein de choses. On apprend du travail des autres, on apprend de la documentation qu’on va lire pour bien saisir ce qu’il se passe, et on apprend de la réflexion que l’on tire du travail étudié.

Le second avantage, c’est que tout le monde apprend. Celui qui effectue la revue apprend, et celui dont le travail est revu apprend aussi, du moment que ce soit fait intelligemment. Un indice : c’est de la merde, recommence n’est pas une peer review intelligente, c’est au mieux une pire review. Des peer reviews bien faites et c’est toute l’équipe qui progresse en même temps.

Le troisième, et non des moindres, c’est pour les gens affectés du syndrome de l’imposteur. Les kudos, great job et autres compliments ont beaucoup plus de sens quand ils viennent de vos pairs que lorsqu’ils viennent d’un supérieur quelconque que vous voyez en entretien deux fois par an et qui ne comprend strictement rien à ce que vous faites.

Enfin, pour celui dont le travail est régulièrement revu et critiqué, il peut donner lieu à une salutaire remise en question qui peut se traduire en une phrase : est-ce que je suis vraiment fait pour ce job.

Mettre en place un système de peer review n’a pas que des avantages. Ou, pour ainsi dire, ce n’est pas naturel pour tout le monde, et en particulier pour les entreprises.

Certaines personnes ne supportent pas d’avoir la moindre critique sur leur travail dès lors que ce qu’ils délivrent fonctionne. Ce genre de tempérament sans remise en question va difficilement de paire avec les startups, mais la peer review peut s’appliquer à n’importe quel type d’entreprise, en dehors de l’informatique.

Il faut ensuite être capable de se donner le temps, le temps de fournir du travail bien fait. Si votre entreprise fait du jetable, ou que votre sprint planning est plus bourré qu’une loutre, ce n’est même pas la peine d’y penser.

J’ai entendu à plusieurs reprises des gens me dire que c’était une perte de temps et de ressources. Ces gens sont probablement les mêmes qui considèrent qu’écrire des tests unitaires ou passer le permis de conduire sont une perte de temps. Parce que oui, je considère les test unitaires comme le permis d’aller en production du code.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: