Quelle sera la meilleure façon de gérer le code source révisé dans un référentiel de contrôle de source? Le code source doit-il passer par un processus de révision avant d'être enregistré, ou la révision du code doit-elle avoir lieu une fois le code validé? Si la révision a lieu après l'archivage du code dans le référentiel, comment cela doit-il être suivi?
Réponses:
Google a les meilleures pratiques de révision de code de tous les endroits que j'ai jamais vus. Tout le monde que j'ai rencontré là-bas est d'accord sur la façon de faire des revues de code. Le mantra est «revoir tôt et souvent».
Supposons que vous utilisiez un processus qui ressemble à ce que Graham Lee a suggéré. (C'est un processus que j'avais déjà utilisé moi-même.) Le problème est que les réviseurs sont invités à examiner de gros morceaux de code. Cela représente beaucoup plus d'efforts et il est plus difficile de demander aux examinateurs de le faire. Et quand ils le font, il est plus difficile de leur faire faire un travail approfondi. De plus, lorsqu'ils remarquent des problèmes de conception, il est plus difficile d'amener les développeurs à revenir en arrière et à refaire tout leur code de travail pour l'améliorer. Vous attrapez toujours des trucs, et c'est toujours précieux, mais vous ne remarquerez pas que vous manquez plus de 90% de l'avantage.
En revanche, Google a révisé le code sur chaque validation avant de pouvoir passer au contrôle de code source. Naïvement, beaucoup de gens pensent que ce serait un processus lourd. Mais cela ne fonctionne pas de cette façon dans la pratique. Il s'avère être beaucoup plus facile de revoir de petits morceaux de code de manière isolée. Lorsque des problèmes sont détectés, il est beaucoup moins difficile de modifier la conception, car vous n'avez pas encore écrit un tas de code autour de cette conception. Le résultat est qu'il est beaucoup plus facile de faire un examen approfondi du code et beaucoup plus facile de résoudre les problèmes modifiés.
Si vous souhaitez faire un examen du code comme Google le fait (ce que je recommande vraiment, vraiment), il existe un logiciel pour vous aider à le faire. Google a publié son outil intégré à Subversion sous le nom de Rietveld . Go (le langage) est développé avec une version de Rietveld qui est modifiée pour être utilisée avec Mercurial. Il y a une réécriture pour les personnes qui utilisent git nommé Gerrit . J'ai également vu deux outils commerciaux recommandés pour cela, Crucible et Review Board .
La seule que j'ai utilisée est la version interne de Rietveld de Google, et j'en ai été très satisfait.
Une technique que j'ai utilisée sur plusieurs équipes est la suivante:
Il est de la responsabilité de l'auteur du code de rechercher une révision et de la responsabilité du responsable de la branche de publication de s'assurer que seul le code révisé est fusionné.
Il existe des outils qui prennent en charge la révision de code, mais je ne les ai jamais utilisés. Le suivi de qui a effectué la révision pour toute fusion peut être effectué à l'intérieur du référentiel. J'ai utilisé des propriétés svn et des travaux perforce attachés aux commits pour montrer qui a examiné quoi.
Je n'ai jamais séparé le code pour examen par des critères validés / non validés - le seul critère que j'ai rencontré est que les tests unitaires et les tests d'intégration sont verts.
En ce qui concerne le suivi, je recommanderais de mettre à jour le flux dans votre suivi des problèmes préféré. Par exemple au lieu de:
Vous voudrez peut-être introduire une autre étape (révision):
Par conséquent, pour chaque ticket à l' état Mis en œuvre , vous pouvez affecter un réviseur et seuls les tickets examinés passeront au contrôle qualité.
Je n'ai qu'une seule expérience des revues de code, donc je ne peux pas dire à quel point c'est bon.
Je travaillais avec un petit groupe (~ 10-15) de codeurs et nous utilisions VS Team Foundation Studio. On nous a demandé de valider le code environ une fois par jour, et avant que chaque code de validation ne soit examiné par quelqu'un d'autre dans le groupe (si tout va bien par quelqu'un aussi impliqué dans le projet). Lors de la validation, le nom de la personne était également inclus dans un champ.
J'ai travaillé sur une équipe qui a révisé le code tout ce qui a été enregistré sur une base de changement par changement au cours de quelques critiques par semaine. Cela signifiait que nous n'étions pas toujours à jour avec les révisions de code, mais cela atteignait ce que nous voulions atteindre.
Alors d'abord, demandez ce que vous voulez réaliser en examinant le code. Dans notre cas, ce n'était pas pour attraper des développeurs idiots, il y avait une hypothèse de compétence plutôt qu'une hypothèse d'incompétence. Cela a permis à l'équipe d'avoir un aperçu des autres domaines du système et a permis de corriger certaines décisions de conception douteuses avant qu'elles ne soient figées. Par discutable, je veux dire qu'il y a toujours plus d'une façon de dépouiller un chat, et tout le monde ne sait pas qu'il y a déjà un couteau à dépecer les chats dans la boîte à outils, pour ainsi dire.
La façon dont nous avons abordé les revues de code était que chaque tâche de notre logiciel de suivi de projet était revue. À l'époque, nous utilisions Mantis et SVN. Nos engagements de projet étaient liés aux deux systèmes. Chaque commit devait être lié à une tâche en mante. Une fois la tâche terminée, le statut "Prêt pour révision" lui a été attribué.
Les éléments RFR ont ensuite été récupérés par quiconque disposait de temps libre pour les révisions ou assignés à une personne spécifique pour révision. Le vendredi, tous les articles RFR devaient être examinés avant la fin de la journée afin qu'il n'y ait pas de report à la semaine suivante.
Les seuls problèmes que nous avons rencontrés avec ce processus étaient de gros éléments qui avaient une tonne de fichiers. Pour gérer cela, le codeur et le réviseur se réuniraient et le codeur exécuterait les modifications jusqu'à ce que le réviseur les comprenne. Ils feraient la révision du code ensemble.
Ce processus est tombé en panne lorsque la direction a dicté que si la programmation par les pairs était effectuée, un examen séparé du code n'était pas nécessaire. Les développeurs sont devenus laxistes sur le processus et de petits bugs stupides ont commencé à être introduits. Finalement, nous sommes revenus au processus d'origine et les choses se sont réorganisées.
Dans mon équipe, nous utilisons une pratique depuis environ un an qui semble très bien fonctionner.
Notre organisation utilise Perforce pour le contrôle des versions. Perforce (il y a un an) comprend une fonctionnalité appelée Shelving. Avec les étagères, je peux "mettre en attente" mes modifications pour un problème particulier. Ils sont stockés dans le système de contrôle de version mais ne sont pas archivés. Ensuite, je demande à un autre développeur de mon équipe de revoir le code.
L'autre développeur peut afficher mes modifications en attente dans Perforce depuis son propre ordinateur et comparer les modifications aux révisions les plus récentes. Il peut également "décompresser" sur sa machine locale s'il veut essayer mes modifications. Une fois l'examen terminé, il me le fait savoir. Je vérifie ensuite mon code avec "Commenté par Bob" à la fin du commentaire.
Cela a très bien fonctionné pour nous. Tout d'abord, les revues de code en général se sont avérées extrêmement utiles. De plus, la fonctionnalité d'étagères de Perforce nous permet de faire les évaluations sans enregistrement ni aucune difficulté majeure, même si notre équipe est géographiquement répandue - ce qui est très important. Et ça marche très bien.