Après, une question conne sur le principe : vous faites la review avant de commiter ?
C'est encore le mieux oui, si on veut être rigoureux.
Donc pas moyen d'avoir un ensemble de commit ?
Je ne suis pas le mieux placé pour en parler, j'en ai une utilisation très basique (via un script maison que je n'ai pas écrit) et en plus avec subversion. Je me contente de soumettre une review à chacun de mes commits atomiques.
Ça ne m'étonnerait pas que Review Board fonctionne avec juste des diff/patch, après tout, le but est principalement de pouvoir donner son avis sur un changeset de sources.
Je ne sais donc pas à quel point c'est laborieux de gérer 40 dépôts différents avec.
Ou alors le commit à reviewer est un commit de merge entre une feature branch et la principale ?
Je ne sais même pas si Review Board s’embarrasse de notions de branches. Peut-être bien s'il veut offrir une intégration poussée aux CSV.
Aucun problème pour convaincre les devs ? Pas de réticences (à l'outil ou même au principe de review et de propriété de code ?)
Dans un contexte d'entreprise, quand le chef dit, on râle un peu et on fait ;)
On a un peu rechigné au départ, c'est normal ; tu ajoutes dans la routine des gars un truc en plus qui a priori leur feront perdre un peu de temps.
Ensuite, ça dépend aussi du mode d'utilisation comme je le disais au dessus :
a) Tu interdis le commit avant review obligatoire par tes pairs
b) Tu autorises le commit avant review pour fluidifier un peu le développement au détriment de la qualité du commit dans l'instant et les commentaires a posteriori de tes pairs permettront de corriger le tir dans les commits suivants
A la longue, on se rend compte que c'est une sorte de filet de sécurité et aussi un moyen de faire circuler la connaissance et c'est même parfois assez ludique.
Après, t'as de tout dans les reviewers : ceux qui vont être obsédés par la syntaxe utilisée, ceux qui font une analyse plus profonde du code et qui arrivent à te débusquer un bug de ouf dans ton algo, etc.
Et question bonus (enfin probablement avant les suivantes) : est-il possible avec ce type d'outil de faire de la review d'un code existant (déjà commité) pour analyser et commenter un code réalisé avant de mettre en place des reviews ?
Sûrement.
En fait, (toujours avec Review Board puisque je ne connais pas les autres outils similaires) quand tu soumets un commit, il n'y a pas que le diff qui est affiché, on peut également aller commenter le code inchangé autour du diff si on veut…
[^] # 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é à 2. Dernière modification le 06 juin 2012 à 16:33.
C'est encore le mieux oui, si on veut être rigoureux.
Je ne suis pas le mieux placé pour en parler, j'en ai une utilisation très basique (via un script maison que je n'ai pas écrit) et en plus avec subversion. Je me contente de soumettre une review à chacun de mes commits atomiques.
Ça ne m'étonnerait pas que Review Board fonctionne avec juste des diff/patch, après tout, le but est principalement de pouvoir donner son avis sur un changeset de sources.
Je ne sais donc pas à quel point c'est laborieux de gérer 40 dépôts différents avec.
Je ne sais même pas si Review Board s’embarrasse de notions de branches. Peut-être bien s'il veut offrir une intégration poussée aux CSV.
Dans un contexte d'entreprise, quand le chef dit, on râle un peu et on fait ;)
On a un peu rechigné au départ, c'est normal ; tu ajoutes dans la routine des gars un truc en plus qui a priori leur feront perdre un peu de temps.
Ensuite, ça dépend aussi du mode d'utilisation comme je le disais au dessus :
a) Tu interdis le commit avant review obligatoire par tes pairs
b) Tu autorises le commit avant review pour fluidifier un peu le développement au détriment de la qualité du commit dans l'instant et les commentaires a posteriori de tes pairs permettront de corriger le tir dans les commits suivants
A la longue, on se rend compte que c'est une sorte de filet de sécurité et aussi un moyen de faire circuler la connaissance et c'est même parfois assez ludique.
Après, t'as de tout dans les reviewers : ceux qui vont être obsédés par la syntaxe utilisée, ceux qui font une analyse plus profonde du code et qui arrivent à te débusquer un bug de ouf dans ton algo, etc.
Sûrement.
En fait, (toujours avec Review Board puisque je ne connais pas les autres outils similaires) quand tu soumets un commit, il n'y a pas que le diff qui est affiché, on peut également aller commenter le code inchangé autour du diff si on veut…