Où le code doit-il être stocké avant la révision du code?

Question

Avis de non-responsabilité Je ne fais pas de révision de code, donc cette question est purement d'intérêt académique.

J'ai vu beaucoup de messages sur stackoverflow qui préconise/nécessite la révision de code avant il est autorisé dans le contrôle de la source. Si vous faites cela, où stockez-vous le code du code non révisé, et comment gérez-vous le problème où le développeur doit mettre à jour le code pour gérer les conflits résultant d'autres vérifications - avez-vous besoin de lui pour obtenir son code? code revu à nouveau?

Merci.

Answer 1

Le code devrait être vérifié dans votre dépôt (SVN, TFS, etc). Vous pouvez configurer une branche de développement (ou même par développeur) si vous voulez l'empêcher d'entrer dans le coffre jusqu'à ce qu'il soit révisé.

Answer 2

Le code non examiné est toujours testé. Et la confiance est une chose importante dans le développement. donc la réponse est que le code appartient juste au système de versionnage. De là, certains l'obtiennent pour examen. S'il y a un problème, il peut être annulé. Tout le reste est juste une grosse bousculade pour rien la plupart du temps. N'oubliez pas que le code dans le référentiel n'est pas "code en production"

Tout le monde doit mettre à jour à partir du référentiel avant de valider. Si vous détectez un grand nombre de mises à jour, il est vraiment possible de relancer les tests. S'il n'y a pas de problème à commettre.

Answer 3

Nous l'enregistrons sur le bureau du développeur. Ce n'est pas vérifié dans SVN parce que ce n'est pas encore fait.

Si c'est beaucoup de code, c'est un problème - vous attendez trop longtemps pour passer en revue.

Si la quantité de code est raisonnable, vous pouvez l'envoyer par e-mail aux réviseurs. Peut-être qu'il a besoin d'un fichier ZIP pour le garder organisé. Parfois, nous l'envoyons à SharePoint, mais c'est rare. Le courrier électronique fonctionne généralement bien.

Answer 4

Mon équipe actuelle procède à des révisions de code avant même d'envoyer des résultats aux parties prenantes. Je suis donc dans le camp qui préconise de ne contrôler les sources qu'après un examen du code. Cela dit, une possibilité est de stocker un fichier de correctif dans un répertoire sur disque au lieu de valider le contrôle de source. Une autre option consiste à utiliser une branche distincte à laquelle les modifications sont validées avant d'être fusionnées avec leur branche cible, mais je crains que cette approche ne soit forcée à péril.

Answer 5

Réponse académique pour une question académique, puisque nous ne faisons pas de révision de code non plus.

TOUT est vérifié dans le contrôle de source. Si ce n'est pas complètement fonctionné/testé/examiné, il va dans la branche personnelle de ce développeur.

Answer 6

Ce genre de pratique est une bonne raison d'utiliser un DVCS comme Git. Les développeurs peuvent travailler pendant de longues périodes sans s'engager, ce qui permet des révisions de code tout en utilisant les techniques de contrôle de version que nous apprécions. Si vous utilisez quelque chose comme SVN, vous devrez vous connecter pour chaque bug/fonctionnalité/tout ce qui doit être écrit et réintégrer après révision du code ... ce qui pourrait être douloureux.

Answer 7

Cela dépend vraiment des types d'outils et de procédures que l'équipe a mis en place.

Pour la révision du code informel, vous pouvez simplement le vérifier dans le contrôle de version et permettre à d'autres développeurs examiner sur leur emploi du temps; les problèmes trouvés par l'examen sont ensuite vérifiés séparément. Pour un examen plus formel du code assisté par un outil, des outils tels que Rietveld de Google et (j'en suis sûr) le Code Collaborator de Smart Bear vous permettent de télécharger du code pour révision et d'avoir un contrôle de version miniature. l'historique de style sur chaque soumission car elle est mise à jour au cours d'une révision. (Si vous êtes intéressés à en apprendre plus sur la révision du code, intelligent ours a un free book sur le sujet.)