Révisions de code pour l'équipe ASP.NET MVC utilisant TFS

Question

J'essaie de trouver un bon workflow de révision de code pour mon équipe. La plupart des questions similaires à celle-ci sur SO se rapportent à l'utilisation des changements mis à l'écart pour l'examen, mais je suis curieux de savoir comment cela fonctionne pour les personnes ayant de plus grandes équipes.

Nous avons généralement 2-3 personnes travaillant une histoire (personne de l'interface utilisateur, personne de domaine/référent, parfois DB personne). J'ai recommandé l'idée de conservation, mais nous sommes tous préoccupés par la façon de gérer cela avec plusieurs personnes travaillant sur la même fonctionnalité. Comment pourriez-vous partager une étagère entre plusieurs programmeurs à ce moment-là? Nous craignons que cela ne soit pas facile et que nous ayons facilement des conséquences imprévues sur ce flux de travail. Bien sûr, passer à des étagères pour chaque fonctionnalité évite d'avoir une dizaine de vérifications par entité (puisque les développeurs ont besoin de partager du code), ce qui rend douloureux les difficultés de révision de code.

Est-ce que quelqu'un d'autre a réussi à gérer cela? Existe-t-il des outils que les gens ont trouvé utiles en dehors des rayons dans TFS (de préférence open-source)?

Answer 1

L'équipe est-elle distribuée? Si ce n'est pas le cas, alors essayez peut-être quelques techniques XP comme la programmation par paire (même si ce n'est pas tout le temps) et demandez aux développeurs de travailler ensemble sur une fonctionnalité. Il est généralement préférable de communiquer en continu plutôt que de désigner des événements spécifiques (comme les révisions de code) lorsque des problèmes sont détectés.

Answer 2

La principale difficulté à l'utilisation de tablettes avec TFS est que vous ne pouvez pas faire de différences entre les étagères sur différentes branches. Vous ne pouvez que comparer à la branche dans laquelle l'étagère a été créée.

En outre, la prise en charge de la mise à jour de vos modifications actuelles avec les modifications apportées par les autres à la bibliothèque n'est pas géniale. Lorsque vous placez une bibliothèque sur la machine locale, l'action par défaut consiste à remplacer le contenu local et non à fusionner. Je ne suis pas sûr si la fusion est même supportée là. Par conséquent, le fait d'avoir plusieurs personnes effectuant des modifications sur le même ensemble d'étagères peut être gênant et risque d'écraser le travail local lors de la mise à jour à partir du serveur.

Pour TFS, vous serez probablement mieux servi en utilisant une branche pour chaque mini-équipe, car vous obtenez une prise en charge complète de la fusion dans toutes les directions.

Quelques autres systèmes de contrôle de version (GIT, éventuellement StarTeam) ont la notion de «branche personnelle». C'est comme l'étagère de TFS, mais il se comporte plutôt comme une véritable branche dans laquelle vous pouvez fusionner vers et depuis, contrairement aux étagères de TFS.

Note de côté: n'ayez pas peur des multiples petits checkins. Vous pouvez différencier les gammes de checkins en même temps pour fusionner plusieurs checkins en un seul diff. Pour ce qui est du style personnel, je préfère souvent faire de petites modifications plutôt que de rester assis sur une révision de monstre pendant des jours ou des semaines (ou des mois!). Les grosses révisions prennent plus de temps à être revues, encourent un risque plus grand que quelque chose soit négligé ou cassé, encourent une probabilité beaucoup plus élevée de devoir résoudre manuellement les collisions de fusion et perdent l'atomicité de suivi 1: 1 d'un bug, un checkin.

La conservation de vos révisions pour un gros enregistrement est parfois appelée workflow "constipé". ;>

Answer 3

Quelques questions de suivi; combien d'histoires courez-vous simultanément, quelle est la taille totale de l'équipe, pouvez-vous faire de plus petites itérations (même si vous ne libérez pas)?

Ne connaissant pas encore les réponses je dirais;

Si la complexité des histoires ne nécessite pas de branches différentes, que diriez-vous juste d'avoir un examen complet du code de tous les changements vers la fin de l'itération? De cette façon, vous voyez non seulement tous les changements, mais aussi comment ils fonctionnent ensemble. Si les gens ne peuvent pas accepter les changements qu'ils ont apportés au cours de cette révision, vous pouvez toujours trouver les changements (mais à ce moment-là vous avez vraiment des problèmes d'équipe plus importants). Selon la taille de votre équipe, cela peut ne pas être pratique.

Une dernière pensée; une bonne couverture de test et une intégration continue sont des sauvetages.

Answer 4

J'ai réussi à faire fonctionner TFS et ReviewBoard.

http://blogs.pinet.ca/tim/2010/08/24/code-review-goodness-with-reviewboard/

Tim