Je vous rejoins totalement et j'ajoute un point :)
Parce que ces deux solutions au problème de cohérence arrivent en fait au mauvais moment. En effet, elles arrivent après que le code a été écrit.
Le problème c'est de faire une revue trop tard. Sauf cas particulier (ou contexte qui ne sont pas ce que je connais), il faut fusionner son code au plus tôt. Outre les effets tunnels (dont la pratique de la revue permet dans une certaines mesure de l'éviter), c'est l'objet de l'intégration continue. Intégrer fréquemment son code ce n'est pas avoir un outil qui lance régulièrement un build et des tests, mais bien le faire de fusionner fréquemment son code. Cela permet d'avoir des revues bien plus courtes (et donc de ne pas overflow le relecteur) et de ne pas risquer de remettre en cause des semaines de travail.
Je sais que ça peut choquer/surprendre de ne pas attendre qu'une fonctionnalité soit complète pour la fusionner, mais avoir des incréments les plus petits possibles aident vraiment (je trouve) pour un tas de raisons.
Une autre solution que je n'ai pas expérimenté serait de créer la merge request très tôt et de demander une revue régulière, mais on perd l'intégration fréquente.
La revue sert à partager l'information et affiner des détails
Et pas à corriger les bugs ! Contrairement à ce que certains pensent.
[^] # Re: L'objectif de la revue de code
Posté par barmic 🦦 . En réponse au lien Mais la revue de code, ça sert à rien ?. Évalué à 3.
Je vous rejoins totalement et j'ajoute un point :)
Le problème c'est de faire une revue trop tard. Sauf cas particulier (ou contexte qui ne sont pas ce que je connais), il faut fusionner son code au plus tôt. Outre les effets tunnels (dont la pratique de la revue permet dans une certaines mesure de l'éviter), c'est l'objet de l'intégration continue. Intégrer fréquemment son code ce n'est pas avoir un outil qui lance régulièrement un build et des tests, mais bien le faire de fusionner fréquemment son code. Cela permet d'avoir des revues bien plus courtes (et donc de ne pas overflow le relecteur) et de ne pas risquer de remettre en cause des semaines de travail.
Je sais que ça peut choquer/surprendre de ne pas attendre qu'une fonctionnalité soit complète pour la fusionner, mais avoir des incréments les plus petits possibles aident vraiment (je trouve) pour un tas de raisons.
Une autre solution que je n'ai pas expérimenté serait de créer la merge request très tôt et de demander une revue régulière, mais on perd l'intégration fréquente.
Et pas à corriger les bugs ! Contrairement à ce que certains pensent.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll