Les "reviewers" sont-ils des personnes dédiées ou ça fait partie des dev ? En gros les devs font la revue des autres dev ?
Chez nous ça ne reste qu'entre codeurs et la règle, c'est de fonctionner par trinôme. Les trinômes se forment pour une période plus ou moins longue ou de façon très temporaire pour une intervention "extra-ordinaire" dans un module spécifique que le développeur ne maîtrise pas forcément.
Chez nous également, un commit = une review, mais c'est parce qu'on fonctionne avec subversion, avec Git ou Mercurial, le plus naturel serait probablement "un push = une review".
Et au final, après un moment, ça donne quoi ? Est-ce que vous reviendriez en arrière ?
J'espère ne pas me tromper en affirmant que la majorité des équipes sont convaincues comme moi par l'utilité du review board (et je ne suis pas chef) car en plus d'être un outil qui va accroître la qualité et diminuer l'entropie des connaissances au sein de l'équipe, il permet d'initier des débats techniques intéressants.
En tout cas, il n'est plus remis en question par qui que ce soit, ça a vraiment bien pris.
En revanche je suis convaincu que c'est le genre d'outil qui, pour ne pas être perçu comme pénible doit vraiment être instantané à utiliser, ça ne doit pas casser le rythme et proposer une interface simple et directe. Une commande à taper et/ou un clic, point barre.
C'est pareil du point de vue du reviewer : on reçoit les demandes de review par mail, en un clic on arrive sur le diff de code, et on peut immédiatement commenter les portions de code et hop, on envoie la review.
Et pour finir, le temps "perdu" en code review, est-il vraiment regagné en réduction / suppression de problèmes, bugs, etc ?
Ouch, faudrait une petite étude pour savoir ça, mesurer la progression qualitative d'un gros projet, c'est déjà pas trivial…
Pour être honnête, les codeurs qui composent le trinôme ont déjà leur propre travail à effectuer et ne passeront pas la journée sur une review, et AMHA les bugs les plus perfides passeront vraisemblablement à travers les mailles du filet, mais ça peut déjà servir à repérer les trucs bien dégueulasses, et à se resynchroniser sur la syntaxe, l'indentation, etc.
[^] # Re: Review
Posté par Guillaume Denry (site web personnel) . En réponse au journal De tout, de rien, des liens, du vrac (des bookmarks quoi). Évalué à 3. Dernière modification le 06 juin 2012 à 21:17.
Chez nous ça ne reste qu'entre codeurs et la règle, c'est de fonctionner par trinôme. Les trinômes se forment pour une période plus ou moins longue ou de façon très temporaire pour une intervention "extra-ordinaire" dans un module spécifique que le développeur ne maîtrise pas forcément.
Chez nous également, un commit = une review, mais c'est parce qu'on fonctionne avec subversion, avec Git ou Mercurial, le plus naturel serait probablement "un push = une review".
J'espère ne pas me tromper en affirmant que la majorité des équipes sont convaincues comme moi par l'utilité du review board (et je ne suis pas chef) car en plus d'être un outil qui va accroître la qualité et diminuer l'entropie des connaissances au sein de l'équipe, il permet d'initier des débats techniques intéressants.
En tout cas, il n'est plus remis en question par qui que ce soit, ça a vraiment bien pris.
En revanche je suis convaincu que c'est le genre d'outil qui, pour ne pas être perçu comme pénible doit vraiment être instantané à utiliser, ça ne doit pas casser le rythme et proposer une interface simple et directe. Une commande à taper et/ou un clic, point barre.
C'est pareil du point de vue du reviewer : on reçoit les demandes de review par mail, en un clic on arrive sur le diff de code, et on peut immédiatement commenter les portions de code et hop, on envoie la review.
Ouch, faudrait une petite étude pour savoir ça, mesurer la progression qualitative d'un gros projet, c'est déjà pas trivial…
Pour être honnête, les codeurs qui composent le trinôme ont déjà leur propre travail à effectuer et ne passeront pas la journée sur une review, et AMHA les bugs les plus perfides passeront vraisemblablement à travers les mailles du filet, mais ça peut déjà servir à repérer les trucs bien dégueulasses, et à se resynchroniser sur la syntaxe, l'indentation, etc.